Join Nathan Phipps at Digital Transformation Asia in December, where he will present a case study on developing a common operations and IT management framework with the Open Digital Architecture (ODA).Since the mainstreaming of business software in the 1980s, IT department strategists have continuously swung a pendulum back and forth between outsourcing (
commercial off the shelf – COTS) and insourcing (custom). Business was first powered by commercial mainframe solutions, then by custom client-server models, then by commercial enterprise applications, then by browser-driven web applications, then by one-size-fits-all software hosted in the cloud. In each case users were dissatisfied with legacy systems and jumped ship to a model that promised reduced total cost of ownership, increased business agility and further technological utopias.
Now in 2018, the pendulum has swung through the wall in the direction of building custom solutions under the aegis of digitization initiatives. Advances in open source, big data, and development methodologies and frameworks have enabled the development of complex and highly user-friendly applications at extraordinary pace. COTS/software-as-a-service (SaaS) deployments which took months or years can now be replaced by a lightweight custom apps running from Spring Boot or Express.js in weeks. As the pace of change increases and the disruption boogie monster hides around every corner, the dangers of being marooned on Legacy Island are only compounded.
Original equipment maunfacturers (OEMs) have tried to ride the digitization wave with mixed results. They face many core challenges:
- Their historically successful products are written under old norms and are now completely outmoded. User interfaces have a kitchen sink approach and don’t translate across form factors. Large datasets are still stored in structured tables. DevOps best practices can be difficult or impossible to follow.
- Fixing the above gaps requires a complete re-write and thus IT Transformation on the customer side.
- Nobody wants to risk a new ‘bleeding-edge’ COTS product. A key reason for choosing COTS is that it is supposed to already be proven out at many customer sites in order to avoid the bug/fix product cycle.
- Ready-made software is not well suited to agile delivery. Often deployments try to show horn COTS software into agile process with sub-optimal results.
- Buying software at all typically requires a long software procurement cycle. Now that we all move at digital speed, this is often unacceptable overhead.
OEMs have had success with SaaS models, primarily in functional areas which are completely replicated across operators. For example, cloud finance and HR platforms have delivered huge benefits; there is no question of building custom
enterprise resource planning. In other areas like customer relationship management (CRM) and configure, price, quote (CPQ), communications service providers (CSPs) have fallen into the same old traps in SaaS that they fell into with on-premise software: over-customization, complex integrations, painful data migrations, and reliance on expensive, niche, proprietary platform experts.
Because of these frustrations most CSPs have embraced software development as a core competency and are rolling out homemade ‘digital’ applications faster than you can say ‘technical debt’.
Digital mania in the enterprise IT landscape manifests as an explosion of custom applications and an ongoing encroachment of the build IT onto the turf of the COTS IT. Each new business capability or feature that can be built faster and cheaper than bought/configured (almost all at this point) expands the build IT ecosystem while the old COTS IT platforms are stuck in neutral.
After the mania comes the crash, which is likely to materialize as deluge of technical debt if key custom governance standards are not followed:
- Develop a product ownership mentality. With no OEM around to provide worst-case support, deep knowledge of every line of custom code must be maintained in perpetuity. Vigilance is required to ensure that no critical component becomes unsupportable.
- Enforce DRY principles across the digital and COTS landscape. Any capability delivered or enhanced in digitization must be completely retired from the COTS. This ensures basic sanity in the IT Landscape and keeps a cap on the proliferation of systems.
- Document and enforce digital standards. There should be one caching framework, one SQL and NoSQL engine, and one UI framework. Although this red tape may seem contrary to the digitization ethos, it will result in significantly limiting flavor-of-the-month proliferation.
Given that digital governance is in place, are there any typical telecom capabilities which are still candidates for the buy-and-configure approach (or the SaaS equivalent ‘subscribe-and-configure’)? Typical questions to be answered:
- Is the requirement a commodity capability which all CSPs do approximately the same way? If so, then consider COTS/SaaS. ERP functions are the obvious examples.
- Is there some competitive advantage to be gained in the market? If so it is critical to build and take product ownership. Clearly, I need tight control of my own self-service mobile app and website to ensure I surpass the capability and user experience of my competition.
- How efficient is custom development? For example, a typical network mediation system connects to network equipment from many vendors and includes built-in translation of network formats. Developing all those interfaces from scratch may not be the best use of my resources.
While advances in custom software delivery have made that option much more attractive, there can still be a place for COTS software in the CSP IT Landscape.