Recent musings in the blogosphere on the demise of service-oriented architecture (SOA) have prompted many of you to ask me for my views on this topic. While I don’t want to address any specific article, I do want share a few of my thoughts on the future of SOA.
In the early days, a joke that made rounds in the tech community was that SOA is a way to finally explain to management what an API is. While good for a few laughs, I think it makes light of a real divide between business and technology. More than just an architectural concept, SOA has helped to bridge the business-IT chasm. And in this role I see SOA going forward and addressing several fundamental issues that businesses face and that IT must resolve.
I recently articulated a notion that I call “timeless software.” In solving the fundamental problems that businesses face everyday, enterprise software must continuously evolve in cycles of renovation by bringing in new functionality and overriding existing capabilities – but doing so in nondisruptive ways. Timeless software is about architecting system landscapes that are always modern and always reliable, and it builds on and extends SOA in three fundamental ways:
Going beyond application/process integration. We traditionally think of SOA in the sense of making system landscapes more flexible. But it turns out that artifacts within a complex system landscape – an enterprise application, for example – need to be consumed in a variety of ways. For example, the UI requires fine-grained and often stateful communication, and we need to provision these out of the applications. Integrating master data requires transactionally safe communication. Analytics and mass data require transferring and transforming data in bulk. And identity – managing the security and access of applications and exposing this to the consumers outside – is yet another type of service exposure. The SOA world is addressing some of these requirements with, for example, service data objects, but we need to go much further with provisioning applications for the multiple forms of connectivity that an enterprise needs.
Flexibility versus optimization. With SOA’s first wave, we took it as a maxim that abstraction comes at the price of optimization. That when we layer software pieces, the additional layer of indirection costs us in performance, that this is a given, and that somehow hardware advances would magically take care of this. Well, it doesn’t quite work that way. Process switches are expensive. Crossing system boundaries and switching across memory hierarchies both consume time and resources, but this is independent of SOA.
The next wave that “timeless software” advances is to flexibly combine content running over multiple containers that can be merged when possible and when necessary, so that principles of locality and performance optimization are maintained. As Alan Kay reminds, this is best achieved by separating meaning from optimization. Again, within the UI domain, we have shown how building UI projections on business objects on the outside, but running these projections within the address space of an application, enables both the flexibility of abstraction, without losing on performance.
The Blue Ruby project (SAP Research project examining the potential of dynamic language-driven ABAP™ program extensions) and several ongoing projects involving JavaScript demonstrate this, as does our work on LiveCache applications, where we run application code and in-memory data management closely together when needed for performance-intensive supply-chain applications. We are taking this work further with executing language runtimes within the TREX engine that powers our next-generation data management capabilities for analytics.
The broader SOA world is also working on this ability to elastically combine runtimes, with work on OSGi containering and on service-component architectures. The OSI network stack got there much earlier, with work on enabling optimization across layers of abstraction. And the work on service-oriented infrastructure (SOI) embodied many of these concepts. Again, we can go much further as an industry with optimizing our runtimes, and SAP can lead the way, using the knowledge we’ve gained about application patterns over the past 35+ years and optimizing the underlying platforms for these applications.
Life-cycle management. The early work on SOA in the industry did not substantially address change management in complex applications and complex landscapes over generations; that is, managing application content, application containers, and their coexistence, modification, upgrades, fixes, and other aspects over long periods of time. We have this knowledge built into our support processes – and they can be made more efficient with technology. But long-lived change management and optimization need to be better defined and explored, and I think this is a key aspect of SOA’s evolution. Within our industry, teams that build operating systems and other infrastructure software (as well as outside our industry in building and construction, aerospace and defense, and in similar domains) have worked for decades on stable interfaces, forward compatibility, nondisruptive system management, and so on. It just hasn’t been addressed yet for the applications I believe defining interfaces for the long run, and creating precise, even machine-readable documentation and software specifications, are key steps in SOA’s evolution.
I’m not planning to write the SOA obituary anytime soon. It’s true that more work needs to be done – and sooner rather than later. SOA is an important and unexploited piece of a very large puzzle, and we still have a long way to go. So let’s do just that.
