Yesterday I held a high level session about S+S at the Basta conference in Frankfurt. After the session I asked some attendees about if the concept (I don't use the term strategy on purpose) became clear. Unfortunately the feedback was mixed. One response I got was even that S+S is not really something relevant for corporations especially for larger ones or enterprises. At this point I realized that I probably did a pretty bad job in explaining the concept as in my opinion it is relevant to everyone using Computers to solve some problem or accomplish certain tasks. This is true especially for organizations. Moreover I would say that most organization are already heavily investing and are implementing aspects of S+S maybe they simply don't know it. This might also be because of the fact that there are many "Services" mentioned in the S+S messaging which are indeed actually targeted at end consumer. So I felt the urge to reflect a bit about all that and try to sum up my thoughts in hopefully easier terms and in a way that the benefits and the conditions under which S+S is relevant to organizations become clearer.
Ok then what is Software plus Services? I think there are basically several statements which lay the foundation of S+S and those are:

  • The Client

    • The fat (smart, rich or whatever you may call it) client is not evil
    • The web with all the attributes and trends around it (social networking, user generated content, etc.) is a truth.
    • Not every application is like the other

      So what does all this mean exactly? It does exactly mean that still (or even especially today) a client application that leverages the power and the quality of services of a PC or other client hardware has its well deserved place in the application landscape. It also means that there are application domains where it seems like some kind of raping to implement those using a web client even in the age of Ajax, Flash and Silverlight. Me myself took a long time to realize that as I used to work for IBM quite a while and was also brought onto the trip that the future of Client applications are thin clients (hardware) and web applications. This was accompanied with statements like "Microsoft" is some ancient relict trying to defend it's heritage by all means (Windows, COM) and that .Net, without knowing exactly what it was at this time, was some kind of last resort and "noobish" try to stop the success of the J2EE platform. I have to admit there were some really great products and frameworks available like WebSphere Portal for example that made it easy to accomplish really great things in terms of moving towards application integration and business process centered presentation and task oriented frontends.
      So it was hard to believe that this would not really be the future. The first time I started to have some doubts about all that was when IBM or later the Eclipse Foundation announced the Rich Client Framework (RCP). Could it be that the messaging before about thin clients was because all of those companies (including SUN with the Java SE) didn't have a client story at all besides of web applications?
      Well today it is some kind of obvious. Most of them were probably really envying the story (which was by no means perfect) and impact Microsoft had on the client PCs out there. Think about the latest announcements yourself and what we have seen recently: Adobe AIR (Client pieces and offline capabilities), JavaFX (Revival of WebStart, dynamic languages and offline capabilities), IBM Workplace Technology (Based on Eclipse RCP, a pure fat client framework). Those are the old players in the application markets and now look what happens. Even the new stars of the web era suddenly show their interest in the client realizing that it is more than a dumb HTML renderer and Javascript interpreter. Google is announcing GoogleGears (Offline functionality and local processing), DoJo Offline (AddOn to Google gears). So there must be some magic around the client and it's capabilities.

      It became even more clear to me when I thought about how I use the PC regardless if as a business or a private person. Ok, I'm not the real hardcore web junky but when I look around in my social environment I can state that nobody really is. And so I must admit that I use fat client applications most of the times when using my computer. I use office software for email, correspondence and calculations to know where I stand with my mortgage. Then I use a video editing program for shaping up videos of my family, same for pictures. And I play games, World of Warcraft, Eve-Online, Call of Duty 4, Counter Strike:Source, etc. So those are the applications I really use at home. Pure web is only interesting for news, shopping and partly social networking. If you haven't already really realized, all the applications I summed up already are some sorts of early evidence of Software + Services. Why? Because I play the games mostly online, some of them are even pure online games, and the also almost all provide some sort of online services. Be it online sharing of pictures, picture print services, transition and audio effect acquisition, instant messaging, buddy lists, in-game chat, voice chat and so on.

      So you see, the fat client is not evil but it gives some perfect opportunity to create some excellent applications if combined with additional (thin) services and presented in a user friendly way. So in other word to create something like a composite application.

      To push it even further, as I realized that on aspect of S+S is the composition of functionality in an application using the best suited client paradigm for the respective functional block it became obvious that to really live this it is necessary to have some sort of architecture that allows you to easily "integrate" those functional blocks dynamically like in a blade center rack where you can dynamically add new blades which then are virtually registering for services of the center like power supply and connectivity via a shared backbone as the blade itself wouldn't be viable alone. Projected back to the software world this "application center" (sorry for the naming) should also provide some horizontal services and registration points so that it is entirely flexible and does not need to know which functional blocks are "plugged-in" and plugged together at some point in the future. Excellent examples of such application centers are really the Eclipse plug-in architecture and the Composite UI Application Block from Microsoft.


  • The Aggregation and Composition Enabler

    • Loose coupling is key whatever you may call it. (be it SOA or Integration Architecture)
    • Standardized interfaces enable

      Looking a little bit more behind the facades of the client but not forgetting what we just said it also becomes quite clear that to enable a client framework to easily create those functional blocks it must be easy to let those visuals with their client side application logic easily consume the meat for their processing hunger. So what does this mean. It means that usually something that is going to be processed by a fat functional block in a composite application is probably already pre-processed by some remote functionality or if it's a thin functional block it is entirely remotely processed. And mostly all major players realized this already quite some time ago and pushed those concepts. And to push concepts (don't get me wrong, pushing things is not always a bad thing) effectively it is better to give it a name so the name most of us probably know is the term Service Oriented Architecture (SOA). And why did they push it really? They did it because thy knew that the future really is the composition of software and services (S+S) and that such a composition simply is far easier if there is a common integration pattern available and this integration pattern got absorbed within SOA.
      Thus another term which is especially used by Microsoft in conjunction with S+S is "Integration Architecture" but both terms in the end mean all the same which is the fact that on prerequisite to really live S+S is to segment functionality in sensible junks and to deliver them using standardized protocols and interfaces respecting the tenets of service orientation.

      Remembering this and going back some years there was a problem with that. Shortly after the year 2000 there was already the mindset or position to have this kind of "universal" client and for example the WebSphere Portal or SAP Enterprise Portal a little later was depicted as frameworks that could be that universal client however the problem was that wherever you went with those great frameworks, there were no SOAs. Companies were struggling to disentangle their application landscape and enable applications to communicate with each other at least on the lowest levels. So the reality in those portal projects often was to do the integration across applications (not functional blocks as those couldn't be extracted from the applications due to their limited architecture) on the frontend level using IFrames which is near to non integration or with sort of screen scraping and heavy Javascript plumbing (Who again said that thin is key and client side processing was evil?).

      Today however the reality is different. There are lots of companies which have at least some of their applications enabled to fit at least into the lower maturity levels and many ISVs that have their applications service enabled. Of course there is still a long way to go for many to reach a level where all surrounding conditions for having a high-end integration architecture with mediation, efficient message routing, governance, etc. have been met however at least the conditions to implement effective composite applications are much better than they were a few years ago. And therefore it is also time to bring the terms SOA or integration architecture in a broader context which again is Software+Services.


  • The Business

    • Not every business needs a self owned software company and IT shop attached to run its business
    • Applications have different attributes and different needs
    • Application assets can eventually be the foundation of new business models

      Ok that one is easy. If you look at large enterprises today, most of them run their own comprehensive IT and run most if not all applications on their own and to some extent even develop those applications on their own. If at all some companies outsourced their complete IT to a big outsourcing company however this doesn't change the basic notion of caring completely about applications and application development as well as the runtime and governance aspects including the huge costs related to that regardless on how important the application may be. To make it clear, there's nothing wrong about that and I'm a big advocate of the principle to have full control over the mission critical applications however there are scenarios and conditions where it is super sensible to check if it does make sense to externalize some parts of the application landscape or enrich application with features which cannot easily be provided by the organization on its own.
      If you realize the power of such composite applications combining internal run Software and external services like British Petroleum did with their Hurricane Warning System then you can hardly believe why this has gained momentum only recently. The homework however then is to decide which applications or functions have to stay more on the isolated, fully controlled and fully customized side of the picture and which ones allow lower levels of data separation, control and customization.
      At a certain point a company may even realize that all the efforts that have been put into enabling integration architectures and moving onto approved open standards could lead to new opportunities in terms of market strategy and business models in the sense that certain function blocks could be externalized by the company themselves. Although this might apply mainly for traditional software companies in the short run it might also be applicable to companies from other verticals as well over time.


  • The Service
    • Services need a deployment architecture.
    • The more horizontal tasks are taken out of the service and are put into a hosting platform the better are the economies of scale

      Here we are again talking about something that has been around as a concept for several years already. It's usually referred to as Software as a Service (SaaS) and is an reshaped descendant of the  Application Service Providing Concept (ASP). But now again the surrounding conditions are different and the drawbacks of the ASP model have been addressed or at least theoretically articulated. Taking the virtues of SaaS seriously and investing some resources into building a powerful service delivery platform with as many shared elements as possible. If you analyze a service in a hosting environment you will see that most of its implementation are things that virtually every service needs to have. So those are pretty good candidates to include them into a service delivery platform and share them across all services.
      Examples for such shared elements are metering, logging, billing, storage, exception handling, etc. This enables economy of scale, and an efficient and easy deployment of new services as they come enabling automation. And just to mention it for completeness this is not only something that is of interest to hosting companies but also for organizations as those in nearly all cases have internal organizational structures which are for the internal line of business units to what the hoster is to the hosting consumer.
      Another aspect that has great impact on economics is the grade of configurability a service provides. So the goal is to deliver a service to a broad audience without having any manual steps in terms of customizing it for the use in the remote customer environment. While it is clear that there must be some compromises the broader the audience gets for a specific service if the service and the delivery platform allow meta-data driven, template based configuration and customizing the fixed cost for the service delivery become lower which has a pretty good impact on the monetarization scheme.

Well now I wrote more text than  intended to initially. So I will sum it up once more. S+S describes the principle of creating value adding composite applications by intelligently combining traditional software, locally running applications and remote services in a frontend which offers a consistent and seamlessly integrated user experience across devices and form factors.  S+S is the sum of three well known architectural concepts or technical and social trends (e.g. the way people interact with software) which are namely SOA, SaaS and Web 2.0.

S+S

So now if you take a look into the portfolio of Microsoft today you can identify no less than four roles Microsoft has in the S+S ecosystem:

Acknowledging all that we see that S+S is the clamp around those principles and we probably can also acknowledge that Microsoft today is the only company that can deliver technology, products, services and guidance for all the disciplines subsumed under S+S. With having the one of the broadest portfolios in the market today for realizing all what was mentioned above it hopefully becomes clear that Microsoft, of all, is coming up with a special term for all that - Software + Services.

Well a lot of text I hope that anyone read so far and even more I hope that anyone was able to follow my thoughts and is now able to better understand the concept and motivation behind S+S. And as a little incentive for those reading to the bottom you can download the slide deck of my Basta Session by clicking on the image link below (sorry folks it's mainly in German).

Basta Slide Deck

And finally a little extra disclaimer which adds to the general disclaimer of my blog:

In the text above I mentioned some Microsoft competitors in conjunction with some critical statements. The intention of those are solely for the purpose of giving the reader a better understanding about the evolution of architectural principles and S+S. They are by no means to be understood as competition bashing or as a try to discredit those companies. In contrary I acknowledge that those companies contributed a lot to the software technology landscape as it exists today.