Cloud Applications = No IT. Not so fast.
Cloud Applications are now being adopted widely in all enterprises. Back end applications like ERP ( Enterprise Resource and Planning ), HR ( Human Resource ), and front end applications like CRM ( Customer Relationship Management ) applications either run in a private cloud environment, or are true Cloud applications that can support multiple customers on a single instance. Workday, Salesforce.com, and Oracle are examples of such applications. These applications have evolved a lot and the need for a lot of IT resources, primarily within the IT infrastructure area, in a company running these applications is shrinking rapidly. However, a company can make a grave mistake when they believe that Cloud applications can run themselves. Many a times, the "You don't need IT", as marketed by Cloud companies, resonates easily with the end users and the executives, specifically when keeping admin costs low becomes the primary driver in tough times. Lack of operational planning is a by product of that sentiment. Once the consulting company is finished implementing the enterprise Cloud application, an organization can completely overlook the needs to hire and retain trained IT resources to feed the dragon operationally for ever changing business environments, upgrades, data extractions and business intelligence needs. After just an year of neglect, the shiny software in the Cloud can become a huge burden for a company, and no executive wants to deal with making even the slightest of mistakes in financial reporting, employee experience and customer relationships.
Taking an application to the Cloud only alleviates the pains of the IT infrastructure requirements to a certain extent, but that's where the benefits end. I am not trying to undermine the benefits of taking the IT Infrastructure to the cloud for an organization, but that's a different topic altogether and the jury is already in. It's all in favor of Cloud vs On-Premise applications. The focus really needs to be towards building a governance model of the RICE components of enterprise cloud application. RICE in my definition stands for Reports, Interfaces, Configurations, and Extensions. I deliberately changed the C in the RICE from Conversions to Configurations, as data conversion is a one time activity during the implementation phase, and it can be done by anyone; either the consulting resources or internal IT resources. So let's discuss the RICE components one by one, but not necessarily in the same order.
Cloud applications have become really slick. Easy to use wizards and well designed user interfaces make it really easy to change application configurations. However, a simple change like adding a Payment Term in an accounting software can impact the entire procure to pay process, reports, workflows, and data interfaces with third party systems. The act of adding the Payment Term is very very simple, but it's the fallout that needs to be well understood and governed. IT resources are typically well versed in end to end impact analysis, and making IT part of the change management and the governance process would help in managing the configuration changes less painful. If you have an IT team member supporting your enterprise application, make the team members part of the Change Board and/or the Governance process.
Complex applications like the Finance, HR, Supply Chain, and CRM applications help businesses orchestrate complex business processes. Many a times, these processes span across multiple systems, both on premise and cloud based. Integration between different systems needs to be well designed, and managed. Often integration requires data exchange across systems using different technologies, standards and languages. IT engineers can provide expertise in this area. Technologies like Web Services, EDI, and even simple file exchange mechanisms are used to exchange and synchronize data between different systems. Data transformations, security, and data quality checks are baked into the designs for exchanging information between different systems. Sometimes the large amounts of data exchange between systems can be a very complex process which requires proper design for scale, and monitoring tools for failure recovery.
Reporting is one of the most important face of business applications. End users use reporting to perform their day to day job. Not too long ago, the IT resources used to spend a lot of time creating simple reports using reporting tools like Cognos and Crystal Reports. However most of the enterprise applications now provide very robust, easy to use, and configurable reporting interfaces. Users can create their own reports easily, export data to Excel spreadsheets, and share the output with other users. Complex reporting, that uses business intelligence tools like Hyperion, Essbase, and Tableau still require help from IT resources. Managing complex data cubes can be a life time of a job requiring a lot of maintenance, especially under ever changing business conditions and needs. Another dimension of reporting that has recently evolved is the concept of mashing up enterprise data with big data, or massive amount of data sets in the Cloud to derive meaningful insights. This has necessitated a need of brand new IT skills in the space of big data. However, only a handful of organizations have a handle on big data.
The last area of focus is the area of extending the Cloud applications to meet a specific company needs. No matter how hard a Cloud application vendor may try, it is almost impossible to meet the needs of all the industries and all the customers across the globe. This necessitates extending the Cloud application. The application vendors provide an extensible framework, using which the IT engineers can extend the application as per business needs. Proper standards have to be used to ensure that an extension survives an underlying upgrade of the technology components from the application provider. This area of software development, if not done right, is the most vulnerable area of ongoing maintenance costs of an enterprise application.
In summary, trained IT resources must be an integral part of the implementation and ongoing operational support team. The devops model is highly relevant for enterprise applications and implementation of enterprise applications has to be done as One Team, both IT and business users together, for it to be successful. The IT team may have to learn the business process along with the rest of the users, and the business users have to understand the importance of proper software development and it's maintenance. Success and failure of the implementation should be shared by both the teams equally, and success measures should have a lead time of at least three years after implementation. If done right, it is highly likely that a company will save a ton of money after the consulting company who initially implemented the software is long gone. IT resources will ensure that proper SDLC methodologies are used by the implementation teams, the components and configurations are properly documented, and plans are in place for IT Service Management after the application goes live. The IT teams can also work with the end users to build automated test cases for ensuring that upgrades from the Cloud vendors do not break all the other complex components ( Reports, Integrations, Workflows etc. ). Security compliance, DR ( Disaster Recovery ), and Internal Audits are still relevant for Cloud applications and IT engineers are better equipped with the skills to handle these very important areas.
Make IT teams an integral part of your organization, your cloud application implementation and operational journey. Reward them the same way as you would reward your own department, and the rest of the company. Happy Holidays, and I wish that your cloud applications treat you right this year.
