Dude, Where’s My Application?
As CTO, Application Services offerings within DXC I find myself struggling these days to identify with the word “application” in relation to servicing modern software architectures. From the perspective of someone charged with strategy for delivering services around the creation, maintenance and operations (CMO) of applications the notion of application disappears into an ever-expanding fabric of transactions and processes. In this universe I find the word application hollow and lacking as a descriptive term to capture what is being built, tested, monitored, metered, and operated.
To the end-user the application is the medium through which they are interacting with this fabric. It’s a website or something they downloaded on their mobile device. They use it to manage their finances, interact with their social network, or edit a document. But for those engaged in CMO the concept formerly known as “the application” is just one facade.
Behind that user interface is a myriad of components, some that support just a single purpose and some that may support thousands of uses, for example, Google Maps. From the CMO perspective, the application is non-existent, in its place is an instance of a solution comprising numerous components serving a particular community. A unique pathway, of many that exist, that connects a given set of software components to derive one particular outcome.
It used to be that applications were a very concrete notion. It was a well-defined, clearly-bounded set of logic encapsulated in a common code base that would be deployed as a unit that commonly included a user interface, data management and business logic. Even in cases where these applications relied on shared services, such as a database service, the application was responsible for defining and managing the structure and actions for the stored data and was typically tightly-bound to how the data was represented within the business logic.
This notion of the bounded logic no longer holds in a “headless”, API-driven, functional universe. The underlying functional services that comprise modern solutions that are typically consumed by multiple presentation layers, e.g. mobile, web browser, other services, don’t necessarily “belong” to a single deployed unit. Indeed, a rich API-based ecosystem based on standards, such as HTTP and Swagger, are enabling greater levels of reuse and sharing, and, in many cases, expanding responsibility for a final product outside the controllable environment.
Hence, the permutations are becoming daunting. No longer is there a one-to-one relationship between the software and a given set of requirements as there was in the notion of applications a decade ago. Servicing the software that in turn services the solution means being able to isolate and articulate the specific components within a given context, expectations for service levels given growing external dependencies, and a means of metering the activities required to ensure health and viability of total user experience. Moreover, it may not be plausible to understand how this “fabric” might respond in every situation, it becomes exponentially difficult to troubleshoot failures, lack of standard service levels for external services results in an inconsistent mean time to repair and requires a level of skilling unprecedented in the industry.
The industry is moving rapidly toward a highly-reactive, policy-driven, event-based ecosystem. The multi-tiered unit previously identified as an application blurs to into the fabric of networked services that is designed to respond to contextual events versus explicitly encoded activities. In this world the responses change dynamically based on the type and context of the event. The same set of services may create a unique experience every time it is engaged depending upon the state of the event triggers and the fabric itself. These are outcomes that previously had to be considered by the developer and explicitly encoded within the bounds of the application unit that are now happening implicitly with the results approximating artificial intelligence.
To see this in action all one needs to do is look at the growth of the voice-based systems from Amazon or Google, where each command is supported by a headless set of logic running in a serverless environment capable of deciphering the speaker’s identity and responding in kind if a child or an adult. In this world, there is no application, just a block of code linked by policy and event to a lexical processor. If that processor interprets spoken language incorrectly, the wrong event will be generated and the outcome is undetermined. Moreover, it should be noted Amazon did not name the this capability an application, they call it a skill. I believe this illustrative of the point that we need a new vernacular to represent this emerging environment.
We are heading toward a great unknown and if we continue to apply the same approaches and practices for CMO defined for applications over decade ago, we will not be able to guarantee the level of confidentiality, availability and integrity we were able to ensure when dealing with a bounded application unit. From the perspective of those responsible for CMO, I believe it’s valid to say the concept of an application is passé and that we need to concentrate our efforts on the fabric and the emergence of a new language to define servicing the elements that comprise the modern-day delivery of automated capabilities.
