Skip to Content

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.

To report this post you need to login first.

7 Comments

You must be Logged on to comment or reply to a post.

  1. Ranjan Baghel
    Thanks for your insightful perspective.
    It’s clear that SAP has put their bets on the future of SOA, and I definitely put my bets on it too. But from my in-field experiences among the SAP user community, it seems that the problem lies more in the fact that SAP has always been a technology-centric world, so it has been a rather challenging transition to shift the focus on the last letter of SOA (Architecture). The driving point is that technology is instead the enabler of a good architecture which bridges the gap between business and IT.
    (0) 
  2. Rick Bullotta
    Vishal, while many of the points you make are valid and relevant, there are other crucial dimensions to broad and successful acceptance of SOA, particularly in the SAP domain.

    One area that has certainly hindered broad-based implementation is the overdependence on SOAP and WS* protocols for exposing SOA functionality, and a lack of support for REST-ful interfaces.  Of course, these are not without implications as well, most notably in terms of expressiveness of service metadata, though there are solutions here.  A related issue concerns security models for consumption of services, which have traditionally been vendor-specific and difficult to work with.

    Another area that is, in my view, largely untapped, is the concept of services being much more than traditional transactional services or query services (the mindset of most BAPI-like thinking).  Services can deliver (and consume) virtually any type of content, from XML data, to images/graphics, to UI-ready content, to metadata, and many many others.  We took this perspective when we created the Lighthammer (now SAP MII) engine, and it opened up a whole new wave of innovation as users/developers were able to compose and consume these services in ways that we didn’t envision.

    Perhaps another flaw in most current implementations of SOA-based functionality is the lack of an event-driven or change-based model for inter- and intra-application communication, which leads to the inclusion of other software components to deal with this functionality, which leads to increased complexity, TCO, and so on.  This is not a trival issue, due to the (theoretically) stateless nature of many services/connections, but it does need to be addressed to enable responsive business applications.  Much of the limitations here lie “under the hood” in the underlying business applications’ inability to provide change or rule-based eventing/execution without coding or other complex customizations.

    And lastly, to your point of SOA’s being another set of APIs, I think this was precisely what led to problems in the first (and second) wave of SOA deployments.  Rather than fundamentally rethinking the business context, granularity and atomicity of services, many implementors (SAP included) wrapped existing functions/APIs.  Of course, some of the later ESA services were significantly better designed, but there was a lost opportunity in the first wave.

    Just my $0.02, after taxes and stimulus subsidies.

    (0) 
    1. Anton Wenzelhuemer
      hi Rick,

      interesting opinion. I wonder if there is any substantial proof or evidence for your statement

      …One area that has certainly hindered broad-based implementation is the overdependence on SOAP and WS* protocols for exposing SOA functionality, and a lack of support for REST-ful interfaces….

      frankly, to me this is a seven (an more) year lasting and repeating tune which did never produce anything comparably sustainable like the SOAP combo (despite latter’s various difficulties). To my knowledge there is usually no one from the REST advocates even trying to propose solutions for fundamental questions emanating from SOAP/SOA implementation lessons learned.

      So where are the REST architecture blueprints for the year 2010, by design not affected by any of the SOAP based SOA pitfalls and challenges?

      my 2 cents,
      anton

      (0) 
      1. Rick Bullotta
        Hi, Anton.

        Don’t get me wrong – “RESTful” interfaces have their own set of challenges, but they tend to be much more easily consumable than complex WSDL with complex nested multi-namespace schemas with custom headers for authentication and so on…anyone who has ever tried to consume an even slightly complex SOAP service from an AJAX client can empathize.

        Actually, it seems that a very high percentage of newly released APIs that I’ve seen for enabling composites (in areas as diverse as GIS, distributed sensor networks, cloud-based services, etc.) are exposing them as REST-like services.

        By the way, I also don’t agree with the “purist” REST approaches that depend on specific semantics for PUT/GET/POST/DELETE etc…rather, I am a fan of simple, expressive web APIs that expose content and capability via a URL.  The problem is that there is no clear/clean way to “introspect” those services today (though, WSDL can almost be used).  I have direct experience in this area, having build a product (now SAP MII) which exposes a very rich set of services using URL-based semantics.  I think there’s even a webcast floating around on the net from an interview I did with Jon Udell a couple years ago in which this was one of the topics.  What it enabled was easy integration of and consumption of those services into a broad range of clients (UI mashups, BPM, custom apps, analytics, etc.).

        It all comes down to “consumability” and knocking down the barriers that limit composition and service consumption to geeks and gurus only.

        Let’s keep the dialog going!  There’s definitely a solution out there…

        Rick

        (0) 
        1. Marcus Schiffer
          Hi Rick,

          thank you for your comment.
          Some years ago I was making a road show for a consulting company on the current hype of those days, the EAI (Enterprise application integration). Using some content from the huge SAP slide repository I was showing a SAP statement that each interface costs about 10.000 $ a year on maintenance and operation. Interfaces were considered to be evil. Integration, Harmonisation and Consolidation were the corresponding buzz words of IT strategists complaining about their complex universe of systems and standards. As a  solution to this problem the EAI middleware (in SAP terms XI/PI) was announced. The promises were the same as for SOA today and EAI was said to be simple and successful.

          Now I feel like having passed a mathematical singularity: From being an evil workaround compromising the idea of integrated IT systems the interface itself has changed to become that central architectual component of a new IT called SOA! And nobody even noticed or complained.  IT managers are eager to step in on the topic, hoping to get some glue that will prevent their IT universe from exploding. They probably think they will get the things back under control with new SOA governance which had already  gone out of hand in the first place.  IT companies are promoting new toolsets and products and the number of standards (WS-*) is growing faster than IT developers can follow. 

          Of course the SOA idea in general is a very, very charming and promising concept. All the benefits that were announced are traceable and may eventually be realized. However, from my experience with the concept one key for a broad adoption of SOA also in the SAP galaxy is still not delivered to the customers today: Simplicity.
           
          The many SOAP and WS-* standards, the ever increasing  infrastructure requirements (PI, JAVA stack, service repository, landscape directory. Forgot something ?) the resulting system landscape and the know how transfer can hardly be managed even within  larger companies. I think over time at least one aspect of SOA reflected by the word  “Simple” in SOAP has evaporated. But not only technology is getting complicated. Triggered by some evangelists companies are also setting up governance bodies and other organisational structures to further corrupt the idea of simplicity.
          So when it comes to solving even a small interface problem who will mess around  with all the needed organisational units: The customer, the middleware group, the process consultant, the JAVA team, the basis guys, the ABAP developer, the networkers, the SOA compliance and governance body ?  The IT staff will simply build it on low budget in the old fashioned way. And it will work.
          This behaviour is also reflected (well, this is not really scientific but seems to be a pretty good indicator) in the number of SDN forum threads on SOA and say ABAP development. As of today the SOA related questions range at about 2000 threads, the ABAP related stuff is more than 300.000.

          So I strongly support your statement on REST also in the SAP world. This seems to be a more simple approach to get (much) interface work done in sync with basic SOA ideas. With REST the individual systems of an even larger landscape gain more autonomy. In SAP we do not need to build and connect all the infrastructure. It can be used more locally adopting many of the successful concepts of the internet. It can be explained in 5 minutes over the telephone. It can be consumed more easy.  RESTful interfaces can be build with far less training. Ok, this comes with more individual development. But I think it is worth the effort.

          Marcus

          (0) 
          1. Alistair Rooney
            Thank you for your insightful comments Marcus. Sadly the implementation of RESTful interfaces would still require most of the technical overhead that traditional WSDL requires. As to the element of complexity, on the face of it REST is less complex, but it can be just as complex as WSDL. The REST architeture – it could be argued – is already used by JavaBeans in SAP. WSDL 2.0 also uses HTTP request method binding now, so the argument is slightly moot anyway.

            Alistair

            (0) 

Leave a Reply