Once upon a time, Software was built as large, monolithic, homogenous code coming from a single vendor. For example, when Charles De Gaulle airport in Paris was computerised for the first time, probably the entire piece of software was sitting all together in one server, perhaps centrally located in the data centre within the airport. All modules of airport operations were perhaps maintained as distinct databases and business processes all within one server.
Today, if a similar airport computerisation has to be done, perhaps the software would be residing in at least 10 different servers, perhaps in diverse corners of the world, each providing a unique service to the overall system. The 10 different services working in 10 different servers would be built by subject matter experts with deep domain knowledge embedded within the software. One service could be WEATHER, another could be FOREX, another could be TIME ZONE. These are simple content services but taking care of all possible permutations and combinations. The FOREX service would be taking the feed on a daily basis from the Reserve Bank of India and similar Central Banks around the world and updating the Rupee – Dollar – Euro conversions for Buy and Sell. It is unthinkable that such softwares could run in isolation without real-time connectivity.
So, how does FOREX service run by a Canadian company interact with the AIRPORT service run by the French authorities?. Is there some bilateral discussion which has happened between the two companies before they signed up ? Was there a Web Services document which was exchanged between the two service providers ? If this FOREX service goes down, will the AIRPORT service switch to another FOREX service provider ? How does the Canadian company charge the Paris airport for the usage of the FOREX service – per month subscription charges or per transaction charges or outright software purchase license ?
Software today has become a collection of distinct COMPONENTS. Each Component does a specific function. If a certain Request with Parameters P1, P2, P3 is passed to it, it will give a certain Response and return Parameters S1, S2 and S3. The value of the output may depend on how the Business Rules B1, B2, B3 were configured, what was the time of the day, who was the user, what was the earlier usage etc. The job of communicating from one SOFTWARE COMPONENT to the other SOFTWARE COMPONENT is being done through APIs – APPLICATION PROGRAMMING INTERFACES. Each Component Manufacturer publishes the APIs related to the service which it is providing.
An example closer home is the Web Services published by IRCTC for Railway Ticket Booking. Many companies and portals such as Akbar Travels, Make My Trip etc may use these Web Servicesto build their own unique front-end screens and response messages. In the back-end however, there are structured messages going to-and-fro between the Travel Agent Server and IRCTC. The APIs will be maintained by IRCTC and continuously updated. If in the Railway Budget, there is a special travel concession for school children, then only IRCTC will modify the response based on the DATE OF BIRTH of the passenger to reflect the discounted fare.
Software Product companies learn to build APIs very early and help distribute the Service to other companies who need these APIs. This is often referred to as SaaS, SOFTWARE AS A SERVICE. During RFP responses, software companies usually highlight the capability of their products to work in SaaS mode. The architecture is said to be SoA, Service Oriented Architecture. The evolution to SaaS has made Software as a Transaction Service instead of a Product Sale. This will alter the way revenue from Software is accounted for in the Balance Sheet of such companies. Software engineers who know how to build APIs and how to read a Web Services document stand a higher chance of rising quickly in their careers.
Author: Chandrashekar Rao Kuthyar Visiting Faculty, CS Dept, SMVITM cs@sangamone.com 08 Mar 2015