There is a big difference between ad-hoc APIs and having a well-planned and well-managed set of APIs that partners--internal and external--can leverage to reuse, evolve, and scale their capabilities.
Innovation is a necessity today, not a choice. Enterprises are waking up to this inevitability but most are chasing innovation by refreshing the business process or user experience on an ad-hoc basis. For them, digital transformation is skin deep, a cosmetic approach that looks good from the outside but lacks a solid core transformation. It is like a smartphone camera that boasts a high number of megapixels but lacks a superior lens. Legacy infrastructure with a digital wrapper is skin-deep innovation.
Innovation, if one-off, is not sustainable. Bone-deep innovation is deep-rooted and sustainable. That is what makes a business agile and ‘programmable’. Programmable businesses take into account the current fluctuating market scenarios and are nimble enough to make tweaks to its infrastructure according to circumstances.
Using an anatomical metaphor, programmability could be seen as the bone around which innovation in the form of muscles develops and finally gives way to the UX in the form of the skin. It’s the bones or the core that should be strong. Similarly, it is programmability that should form the base above which the infrastructure of innovation and user experience should be built.
The primary component of bone-deep innovation is optimizing the potential of APIs. There is a big difference between ad-hoc APIs and having a well-planned and well-managed set of APIs that partners--internal and external--can leverage to reuse, evolve, and scale their capabilities. Building ad-hoc APIs just for the sake of it doesn’t refresh the backend processes. It only improves the UX momentarily but does not make it sustainable or ties it back to a programmable tech DNA. To enhance APIs, one needs to identify what kind of APIs are needed based on business objectives, how much will they be regulated, what each API would do, and finally deploy them. The API program is not a one-off process, but an agile model. One needs to constantly monitor it through management tools to regulate access if required and use them at scale.
According to ProgrammableWeb, API adoption has surged more than three times--from about 5,000 APIs in 2012 to 17,000 in 2017--with social and financial sectors being among the most popular API adopters. Enterprises are increasingly recognizing the benefits of APIs in decreasing effort to scale business, increasing access to solutions, and providing customizations. While Salesforce generates 50% of its revenues via APIs, eBay’s figures stand at 60% and Expedia, a whopping 90%. IBM has earmarked $1bn for the commercial use of its AI Watson via APIs.
A good example of how a legacy enterprise has opted for bone-deep digital transformation is Lufthansa. Founded in 1953, the 32bn euros company wanted to arrive at solutions in a short time and also spur innovation in the enterprise. Recently, Lufthansa’s Innovation Hub partnered with DXC Technologies and implemented an open (yet controlled) API program that serves its 100 million passengers. With an increase in brand visibility and precise targeting, sales took a jump. The program also improved travel experience for customers and positioned Lufthansa as an innovative organisation. Qantas Airlines too is investing on placing REST APIs in front of their legacy systems. It has further plans to add SOAP API support to “unlock value from their legacy services”.
In contrast, look at Blockbuster which was a powerhouse in the world of video rentals in the 1990s. It boasted over 8,000 stores at one point of time. However, with limited commercial data in the digital domain and lack of proper technological shift, it had to shut shop in 2013. In the same year, BBC’s doomed Digital Media Initiative had the company write off GBP100mn worth of assets and sack its CTO. An audit by PwC highlighted that BBC assumed that digital transformation was all about solving technological problems while failing to realize that a cultural, behavioural, and capability shift was also required. In 2016, BBC announced another digital transformation initiative pegged at GBP289mn. This year, it has entered into a five-year contract with Atos to provide technology services. The new contract results in the reduction of costs by one-third.
Innovation in the post-app era is not about building separate apps for various needs but building a select few with a strong focus. Apps shed their baggage of noise and irrelevance and turn microapps. They are economical, focused, cleaner, lighter, and easier to boot--and highly compatible to all personal devices. Instead of spending months to build a bulky app, developers can rapidly make smart and highly focused microapps. Cases in point: Facebook Messenger or any weather forecast app.
The ‘easily pluggable’ and highly customizable nature of microapps makes it agile. Microapps are to enterprises what a buffet with bite-sized portions is to restaurants. They are focused, very accessible, and highly alterable. Microapps can easily be integrated to existing software platforms. Enterprises which build and deploy apps that bring together internal communication, HR policies, leave management, social media etc are programmable. Employees can have access to relevant services at a click on their personal device and this increases satisfaction as well as productivity.
On another level, WeChat is an aggregator of microapps and that is what makes it so programmable. One can chat on it, book a cab, transfer money, and even order a burger. Microapps also leverage the power of APIs and are one of the precursors of bone-deep innovation.
A killer feature of programmable businesses is their ability to deploy apps and microapps at scale. The ability to deploy on various cloud platforms--Google, Amazon Microsoft or hybrid--and the ease at which they can be shifted across seamlessly based on market/ tech demands is the essence of innovation in a programmable business. Faster deployments with increased confidence builds trust in users and thereby boosts business. This is also a precursor to effective support, monitoring, and managing of the apps deployed.
The idea is to shift fast. According to the Progress Global Survey 2016, 86% enterprise decision makers feel they have a time of two years to either digitally transform or concede financial losses. Thankfully, based on the Global Digital IQ survey by PwC 2015, 53% companies have a transformation blueprint that includes IT as well as business shifts. The transformation should take into account business capabilities and processes as well as digital and IT components.
Real innovation is beckoning. Are you listening?
You start with the customer experience and work backwards to the technology. You can’t start with the technology and try to figure out where you’re going to try to sell it - Steve Jobs
The mass-market economy is turning extinct and so is its make-and-sell business model. On-demand chain is topical: it starts from the customer and ends with the delivery of an on-demand solution.
On-demand chain is driven by a fickle market and it means continuous change, which is not achievable without digital transformation. Hence, software needs to drive value. They become the managers who coordinate work and manage it. Human management becomes a liability. According to a McKinsey report, by 2025, automation innovations will replace 250 million knowledge workers worldwide.
Conway’s law states that the information systems of an enterprise reflect its communication structure. In such a situation, a company’s org chart is best not left rigid and unbending. Static business models don’t create market leaders anymore. Programmable businesses do. Programmable businesses are a result of digital transformation. They survive with relevance and lead to innovation.
If enterprises are not dynamic, dispersed, and de-siloed, we can only expect the IT systems to be based on legacy infrastructure. In short, in no time, they will get pushed out of the market.
The shift is from a firm organizational set-up to a de-siloed working model. Projects are broken down into smaller pieces, each operated and managed by a small group of people. These pieces of work are easier to manage and deploy, but not at the cost of rigid communication flow. Communication, decision-making, and social capital are at their best within dynamic branches.
The IT system mirrors this shift--from monolithic apps to nimble microservices. Just like a de-siloed enterprise, microservices are broken down into multiple component services. Each of these services can be deployed, tweaked, and redeployed independently without compromising the backend service architecture. A change made to a small part of a monolith app needs the entire monolith to be rebuilt and deployed. Microservices are independently deployable and scalable.
Today, brands are embracing a fluid org chart and evolving from monolithic to microservices architecture. eBay’s central application comprises various autonomous applications, and each functions in different areas. Amazon has also migrated to microservices. They get countless calls from a variety of applications—something that would have been unachievable with their old, two-tiered architecture. Netflix receives more than a billion calls every day, from multiple devices to its streaming-video API. Each API call leads to around five additional calls to the backend service. Twitter, PayPal, Soundcloud, and The Guardian are other companies that have showcased their innovation and struck gold with microservices. All these points at their flexible and programmable organization structures.
The movement is also from central management in an enterprise to a more dispersed share of control. Decentralizing control deters bureaucracy in an organization. IT systems follow these footsteps and open their APIs to make handpicked resources available to developers/ customers/ competitors/ employees and also leverage shared APIs to build their own apps. Disaggregation of business functions optimizes productivity and leads to contribution to the API economy. Today, companies like Apple, Google, and Amazon are leveraging the strength of APIs to build their businesses, which are programmable in nature. This leads to innovation.
Innovation is the present and will determine the future. Programmable businesses will lead to smart machines communicating with one another without human intervention. Vending machines can become their own profit and loss centers, autonomous cars can drop you to work, and so on. Companies like Citi and NASA are participating in hackathons to generate new prototypes.
Everything ties back to how agile one’s org chart is and how programmable one’s business is. Google Maps shows us the fastest route to a destination, but it also shows an alternate route... just in case.
With API-driven development having API as the fulcrum, your app will not just survive but also thrive in this connected world
The ubiquitous question of "What are APIs?" has been answered in multiple forums. Let's start with a more interesting and relevant question: “Why APIs?”
The most important aspect of “Why APIs?” is that it brings in the standardization of interfaces in the development process. Developers get to work on structured and standardized APIs that are bound to not change their underlying behavior, irrespective of the technology or components used underneath.
APIs also take care of hiding the complexity of underlying implementation, bringing in modularity and separation of concerns, which lets independent decoupled services to be implemented and tested.
The proliferation of SaaS applications with exposed web APIs gives a new dimension to application development in which the developer has to focus on coding just the application business logic. Other subsidiary services (such as user management, logging, dashboards, deployment, etc.) are made available by calling these services (third-party or in-house services) through APIs. This speeds up the app development time manifold.
The business answer to “Why APIs?” is even more intriguing because APIs act as gateways to enterprise digital assets. Organizations treat APIs as an important revenue channel. In fact, in some organizations like Salesforce.com, APIs contribute to more than 50% of total revenue. The ability of APIs to generate revenue by monetizing digital assets has ushered in a new way of shoring up enterprise revenues. This phenomenon needed some new jargon, so the world called it the API economy.
An API-first design is where the API is the first artifact that is created during the app development process. API contracts (API specification and signature, including the name, parameters, types, etc.) are either created by dedicated API architects or by front-end developers who are responsible for creating the end user experience. API contracts are finalized in collaboration with front-end and back-end developers.
Once the API contracts are finalized, the front-end developers build mocks around APIs and create and refine the end-user experience. In parallel, the back-end developers implement the underlying logic of the APIs. Dedicated test suites are created around these APIs and, in a way, they foster the idea of test-driven development. Finally, the implementations of the front-end and back-end developers are brought together. This is bound not to fail as long as the developers have coded honoring the API contracts as established in the first step.
At a code implementation level, APIs these days are typically designed using the REST architecture with JSON payloads. SOAP, XML, and other standards are found to be heavy and heading towards oblivion.
In addition to the benefits of APIs listed under the “Why APIs?” section, API-driven development adds its own set of benefits to make the life of a developer easier and the process of app development simpler.
ADD allows the developer to focus only on the business logic. In ADD, it is expected that all subsidiary services will be accessed through APIs. Also, the initial agreement of the API contracts, parallel implementation by the front- and back-end teams, and hassle-free merging of the front- and back-end code bring about huge time savings in app development.
It is expected that the developers will use APIs (third-party or internal) for all the subsidiary services like user management, logging, etc. Hence, the focus of development is purely on the implementation of business logic and not on spending time implementing the skeletal technical structures of the app. In fact, in the thriving API ecosystem, API marketplaces (like ProgrammableWeb and Mashape) have come up to make the process of discovering and consuming the required APIs much easier.
One thing you will observe in all the enterprises who have made it big in API economy (i.e., Twitter, Expedia, etc.) is that their APIs are easy to use. Their APIs are easy to find and they have great documentation. An effective API is defined by an effective documentation around it. In fact, there are API tools like Swagger that have sprung up to aid in the process of describing and visualizing web APIs. In summary, a positive side effect of ADD is great API documentation, which typically is a neglected aspect of the traditional product development process
One of the aspects we discussed in the “Why APIs” section was modularity. Apps developed using ADD tend to be modular in nature, with every module representing a service (third-party or own). The main application itself seems to be a collection of microapps talking to each other using APIs. This app architecture is called microservices and has its own set of benefits. For example, If there is a load on the user management service of a microservice-architected app, we can scale that user management service by adding more hardware resources. Compare this with traditional monolith app architecture, where the entire app has to be scaled, though only a part of the app needs scaling.
With the proliferation of smart devices and the evolution of the API economy, we are heading towards a digital world (i.e., Internet of Things) where everything is connected through APIs. With API-driven development having API as the fulcrum, your app is will not just survive but also thrive in this connected world.
ADD is a powerful development process and is gaining prominence among IT teams in various organizations. What are the typical lifecycle phases of an API? What can be done to make ADD as the default development approach in organizations? Let's discuss those questions and more in later posts, where we will talk about API life cycle and the next-gen ADD.
Big U.S. banks will continue to add partners to access customer banking data. This is a marked change in their stance from an earlier position of reluctance
2017 could be a watershed year for how U.S-based banks and third-party app providers share data with each other. Since the start of this year, two U.S. banks (JPMorgan Chase and Wells Fargo) have made significant announcements about their agreements to share data with Intuit securely through APIs.
This is a marked change in the stance by top U.S. banks from their earlier position of reluctance towards allowing third-party personal finance management apps to access their customer banking data. Since there was no formal agreement of data sharing between banks and third-party apps, the latter--like Intuit and Yodlee--had to adopt the older insecure approach called screen scraping. The user has to provide her/ his banking username and password to these apps. These apps will then automatically log in using those user credentials, screen scrape the bank data, and use it for reporting in its apps.
This is problematic on multiple levels, the most important being that the user has to share user credentials with third-party apps. From the bank’s perspective, there is a heavy load on their servers, and this is affecting their banking website performance and operations.
However, the explosion of smartphones and mobile apps and the evolution of FinTech companies have created an environment where third-party apps have become indispensable--a situation that the banks dislike, and their banking apps will never be able to replace them in terms of their effectiveness. In fact, banking regulators in Europe realized this a while back and instructed their banks to share data through APIs.
The agreement between JPMorgan Chase and Intuit says that they will introduce Open Authentication and will exchange data through the Open Financial Exchange (OFX) 2.2 API. JPMorgan Chase customers won’t have to provide their banking usernames and passwords since the technology will use an API token-based approach to authorizing Intuit apps to download the requested account information. Similar to the way apps in the social media world operate using OAuth, you can expect third-party apps to ask permission to access sensitive banking data. This is a huge improvement—you end up only sharing particular information in your bank accounts instead of the entire data being screen-scraped.
Good news for all the tech and citizen developers out there in the FinTech industry is that these big banks are not going to limit their partnerships only to Intuit. Banks are going to add more and more partners to access their customer's banking data. Therefore, there is an opportunity waiting to make it big and innovative with live bank data. What are you waiting for?
Is enterprise agility related to business strategy? Is it the same as digital transformation? Or is it about flexibility? Here is an explainer
Enterprise agility (EA) is a company’s ability to outperform the competition and drive growth by learning and adapting when confronted with foreseen and unforeseen circumstances, dilemmas, crises, and complex problems.
That’s a broad definition.
Let’s use a metaphor. How fast does information move from the edge of your organization to the center? Just like a gymnast, an agile organization needs close connections between its senses and its ‘muscles’. This can be achieved by pushing the power out to the edge of the organization. Or by smoothing the pathways of information to the center. This is achievable with the technologies of today--especially with the rise of the API economy.
When we talk about projects and enterprise agility, it is about the ability to quickly organize and make the best use of the resources within the organization to deliver those projects. An enterprise being able to structure itself in a way that allows quick deployment of the right people to the projects; being able to establish governance practices that allow both quick and delegated decision-making; and standardizing key processes (creating a stable backbone) where everyone is talking in the same language--all these are factors that lead to an increase in agility and performance.
Not quite. Digital transformation is mostly about adapting your business offering to a digital era. The considerations are more strategic. We talk about catering to digitally savvy customers and omnichannel customer engagement. Once you have decided on a business strategy, however, the question that naturally arises is, ‘How do we go about it?
EA deals with the ‘nuts’ and ‘bolts’ of this adaptive ability. The considerations are more technical. We speak of Intra-departmental APIs, rapid app building platforms, and collaborative micro-apps. You could say digital transformation is about the market-facing side and enterprise agility is more inward-looking. EA is what allows the enterprise to ‘do’ something about market needs. EA is about organizational mechanics.
A lot of people, when they think of how they design the organization, immediately gravitate towards the management hierarchy—the lines and boxes. But that’s just one small element of how you set up the organization. The structure also includes governance and how you set up committees; how they can approve things and make which decisions; which authorities get delegated; what is contained in a role and what people get to decide. This is all part of the structure. But the org chart actually comes in the way of making real-world business decisions. Not infrequently, teams need to network, collaborate, and form task forces to get things done. Add to that the fact that enterprises have global footprints now. IT is the big deal here. Without IT, the question of enterprise agility simply doesn’t arise.
Gartner, IDC, Forrester
A greater reliance on digital will bring new challenges: The typical IT organization will spend up to 30% of its budget on risk, security, and compliance by 2017, and will allocate 10% of IT staff to these functions.
In order to excel in this dynamic landscape, companies need to be programmable. Programmable here isn’t about coding but the very nature of a company. Such companies are fluid and quickly embrace the fact that they do not know everything.
The insertion of metal gates in a microchip was a stirring moment in computing. The year 2007 marked the beginning of a technology era that became chaotic by default. Most of what we term as native digital innovations including Airbnb, Android, Twitter, Kindle, and even IBM Watson came into existence in this period. Disruption became an outdated term, markets started to get dislocated. Sample this: The cost of sequencing a person’s DNA fell from a staggering 100 million dollars to about 1,000 dollars.
Storage, processing, networking, software, and sensors started fusing rapidly (a.k.a The Cloud) to create platforms that scaled up capabilities and reduced time to market. Ideas started becoming products and products scaled instantly--creating companies that made competitor sets routined and industry boundaries vague. From then, the rate of technology growth has simply outpaced an organization's ability to learn and adapt. While policymaking constantly plays catch up, organizations aren’t given a long rope to respond, adapt, and evolve.
In order to excel in this dynamic landscape, companies need to be programmable. Programmable here isn’t about coding but the very nature of a company. Such companies are fluid and quickly embrace the fact that they do not know everything. They design structures and processes that are loosely coupled around a fixed core. Being programmable is about dynamic stability. Technologies like API, Microservices, Cloud, and Mobile are helping companies to create an agile fabric where business users, customers, and developers can collaborate. This fabric creates enterprises that are absorptive to fluctuating market needs and thereby programmable.
The agile fabric is the technology line-up that businesses need to make themselves programmable. It is the most efficient and valuable path leading from the assets of an enterprise to the customers it serves. Here is a rundown:
At the heart of a programmable enterprise are its APIs. Businesses decide the set of assets and services that should be accessible by their stakeholders and start exposing them via APIs. Such APIs reduce interdepartmental information barriers and give modularity that helps in de-siloing the enterprise. Banking enterprises like Citi and Bank of America are already leading the way in this API-driven open architecture model.
Enterprise developers and business owners can leverage such exposed APIs to create apps that help them automate a specific task or entire business process. To accelerate the pace of creation, RAD tools are used. Such RAD tools offer templates, prefabricated code modules, and out-of-the-box onboarded APIs for widely used tools, thereby allowing stakeholders to develop apps with simple drag-and-drop.
Consider this--developers who use Visual Studio would prefer Azure because of the seamless integration it has with Visual Studio. But data scientists, who are creating AI algorithms for automating customer care functions, might want to leverage Google’s Cloud Platform for the extensive AI capabilities it supports. To manage this diversity at scale, the old-school way of making an infrastructure choice and running it for a decade won’t cut slack anymore. Infrastructure and data platform choices need to be made on-demand. Leveraging infrastructure integration solutions enables businesses to seamlessly switch between multi-cloud, on-prem, and hybrid deployments. It also gives the needed compliance, governance, and infrastructure adaptability that enterprises need to support emerging users and use cases.
Once apps are available for enterprise-wide consumption, issues like multi-screen support, access control, availability, usage metrics, and analytics come up. This is important because the consumption layer is a user-driven layer and directly impacts the way users (internal/ customers/ partners) perceive the business. Touchpoint engineering solutions allow enterprise apps to have streamlined front-ends, central update mechanisms, admin consoles, and cross-platform rendering capabilities. Such solutions help enterprises deliver an omnichannel experience with zero set-up time.
The Agile Fabric: acting across value areas to bring about business agility
By adopting solutions that aid in the creation of the agile fabric, enterprises become programmable. Programmable enterprises desert their time-tested solid base that gives stability and graduate to a moving base that provides agility. They finally start to move with their markets. And most importantly, only they survive.
You must have heard this multiple times by now. Artificial Intelligence is not coming, it's here. Cars are already driving themselves. Warehouses are working by themselves. Many of the support calls are now answered by bots. Virtual assistants are helping us in perhaps everything from finding the nearest chemist store to the best restaurants.
Major AI players like IBM Watson, Google API, AWS, Microsoft are all working towards providing usable intelligence to enterprises so that real-world problems can be solved easily. Common services they offer include intelligent search, a conversation that can be trained, speech to text and text to speech, and other than core ML libraries.
Let’s take an example. Organizations may need a Chatbot that can create PTO / vacation days for employees.
This kind of conversation can be configured in IBM Watson Conversation as below.
For more information on creating the dialog, please refer to this.
This is all based on UI-based configuration. Other than that, you can also train your bot for intents. For example, I may ask to apply for vacation in different ways.
Now the conversion is all prepared in IBM Bluemix.
To experience this conversation in applications is important. But, building a quality application with these services is still challenging. Delays due to the unavailability of resources or skills should not stop you from realizing AI benefits.
Low-code application delivery tools facilitate the ease of integration of these AI services. WaveMaker (a low-code platform) provides out-of-the-box components (aka “prefabs”) to have a Chatbot that can provide the front end for Watson Conversations.
Developers simply need to drag and drop the Watson Chatbot prefab and configure the conversation workspace and its related authentication.
If you need any help with building your AI applications, please email me at email@example.com.