Comments on: More on Level 4 Platforms http://blog.joeandrieu.com/2008/07/08/more-on-level-4-platforms/ My personal space Tue, 16 Mar 2010 20:51:45 -0600 http://wordpress.org/?v=2.8.3 hourly 1 By: Equals Drummond » Blog Archive » Joe Nails it Open http://blog.joeandrieu.com/2008/07/08/more-on-level-4-platforms/comment-page-1/#comment-1496 Equals Drummond » Blog Archive » Joe Nails it Open Mon, 14 Jul 2008 06:56:22 +0000 http://blog.joeandrieu.com/2008/07/08/more-on-level-4-platforms/#comment-1496 [...] Andrieu nails another super post (where DOES he find the time to write/draw all of these???), this time about what it means for a [...] [...] Andrieu nails another super post (where DOES he find the time to write/draw all of these???), this time about what it means for a [...]

]]> By: Joe http://blog.joeandrieu.com/2008/07/08/more-on-level-4-platforms/comment-page-1/#comment-1493 Joe Sat, 12 Jul 2008 06:28:42 +0000 http://blog.joeandrieu.com/2008/07/08/more-on-level-4-platforms/#comment-1493 Absolutely, there is nothing saying that Level 3 platforms can't interoperate. I can run parallels on my Mac, for instance, to have Windows and Mac interoperability. As I tried to make clear in the conversation at Caltech, I think Salesforce has a lot to offer potential developers: speed-to-market, a rich, complete feature set, and built-in access to a ready market that has proven it will pay for third-party apps integrated with the Salesforce application. But at its core level of service, it is still not an open platform as I describe. (Which I think we are in agreement about). If users could pull their code from force.com and run it with minimal changes and no loss of functionality at another service provider, then I would agree that it meets the definition of an open-protocol 4th level platform. Those protocols would be the shared APIs of the underlying service layer and the interfaces of the programming languages. However, my understanding is that a large part of the code written for force.com is in a proprietary language with exclusive force.com APIs. Which means business owners don't have an easy option to move their service elsewhere. Of course, this wouldn't prevent a business from developing its system to work with Salesforce /and/ a number of other services, such as Facebook or NetSuite, but that's a way to diversify through investing additional resources, rather than mitigating risk by choosing an open platform for the limited resources you do invest in technology development. What your point highlights is that for a subset of specific functionality at Salesforce.com, the user is locked into a proprietary framework. Of course, they may connect what they build in that framework to other open systems, and can access the application through any standards-compliant browser, but it is still proprietary. Absolutely, there is nothing saying that Level 3 platforms can’t interoperate. I can run parallels on my Mac, for instance, to have Windows and Mac interoperability.

As I tried to make clear in the conversation at Caltech, I think Salesforce has a lot to offer potential developers: speed-to-market, a rich, complete feature set, and built-in access to a ready market that has proven it will pay for third-party apps integrated with the Salesforce application.

But at its core level of service, it is still not an open platform as I describe. (Which I think we are in agreement about). If users could pull their code from force.com and run it with minimal changes and no loss of functionality at another service provider, then I would agree that it meets the definition of an open-protocol 4th level platform. Those protocols would be the shared APIs of the underlying service layer and the interfaces of the programming languages.

However, my understanding is that a large part of the code written for force.com is in a proprietary language with exclusive force.com APIs. Which means business owners don’t have an easy option to move their service elsewhere.

Of course, this wouldn’t prevent a business from developing its system to work with Salesforce /and/ a number of other services, such as Facebook or NetSuite, but that’s a way to diversify through investing additional resources, rather than mitigating risk by choosing an open platform for the limited resources you do invest in technology development.

What your point highlights is that for a subset of specific functionality at Salesforce.com, the user is locked into a proprietary framework. Of course, they may connect what they build in that framework to other open systems, and can access the application through any standards-compliant browser, but it is still proprietary.

]]> By: pCoffeeSFdotC http://blog.joeandrieu.com/2008/07/08/more-on-level-4-platforms/comment-page-1/#comment-1489 pCoffeeSFdotC Tue, 08 Jul 2008 16:53:46 +0000 http://blog.joeandrieu.com/2008/07/08/more-on-level-4-platforms/#comment-1489 What seems, to me, to be missing here is the possibility that there are multiple Level 3 platforms that offer high-leverage internal APIs while also enabling open protocols to interact with other systems and resources. There could be interaction at the level of the application environment (application integration) and also at the level of the user interface (the simple mashup), as suggested by the figure at http://wiki.apexdevnet.com/images/b/be/Level3Openness.gif There's no reason why a Level 3 platform can't offer the rapid time to market of its own high-leverage facilities while still letting developers exploit other facilities, or hedge their bets by reserving some of their code base to run in another environment. What seems, to me, to be missing here is the possibility that there are multiple Level 3 platforms that offer high-leverage internal APIs while also enabling open protocols to interact with other systems and resources.

There could be interaction at the level of the application environment (application integration) and also at the level of the user interface (the simple mashup), as suggested by the figure at http://wiki.apexdevnet.com/images/b/be/Level3Openness.gif

There’s no reason why a Level 3 platform can’t offer the rapid time to market of its own high-leverage facilities while still letting developers exploit other facilities, or hedge their bets by reserving some of their code base to run in another environment.

]]>