Tag Archives: Application Infrastructure

“Private Cloud” and RIA gain momentum alongside SaaS

I wanted to share with you some results from a campaign we’re just concluding. The campaign targeted at CIO’s and Chief Architects of Switzerland’s large enterprises. We asked them about their interest or experience with RIA and Cloud development and implementations. Over 16%  responded positively – are both developing in-house and considering RIA’s.

I think that we see here a fundamental architectural shift, which is more visible perhaps in the SaaS application market but is nevertheless gaining significant foothold as “private cloud”.

It might be useful to segment the SaaS phenomenon between the Usability aspect and the Business Model. Private Clouds and RIA go after the Usability, which I start to think is a stronger driver than the Business Model.

Bookmark Avigdor Luttinger’s Blog

Advertisements

The coming out of the hybrid SaaS model

The current controversy that considers SaaS as mutually exclusive with On Premise is, in my view, more related to the current state of technology, than to business or functional issues.

Clearly, if On Demand applications have to be developed and deployed on entirely different platforms and technologies (RIA and multi-tenant) than On Premise applications (Windows and JEE or .NET), then it is difficult, cumbersome and costly to support both.

 The topic is not a theoretical issue – I consider it the critical enabler for the growth of SaaS. The majority of ISVs are facing a tough challenge when it comes to offering SaaS as they and their customers are looking to cut costs, yet to offer a SaaS portfolio an ISV is faced with a potentially large upfront investment needed to offer a SaaS version of their products. I will expand on the ISV challenge in a separate post.

 That is not a pipe dream – the first application platforms that supported this proposition (Magic Software’s uniPaaS) hit the market almost a year ago, and just recently PaaS provider Longjump announced an On-premise version of their PaaS. There’s even persistent speculation that Force.com would follow suite.Clearly, on-demand business requires a different business approach than on-premise – but I view it rather as a super-set than a mutually exclusive path. And as we see in the SaaS integration business, many vendors offer a SaaS pricing models to on-premise installs – and doing so for applications should not be much different (assuming customers provide a compliant infrastructure and operate it).

 Now, consider the proposition in which the same application platform (and consequently application) supports various deployment modes (single and multi tenancy, Fat, Browser or RIA client). The Client appliance aspect becomes immaterial. A software vendor using such a platform can unify its development and support cycles and have a single cycle of updates and upgrades. The SaaS hosting center (and not necessarily only one) becomes yet another “on premise” customer, hopefully with many more users than a “regular” on premise customer. And customers have the power of choice and can evolve and migrate their software usage in accordance with the evolving business requirements.

A battle royale for RIA market? Isn’t something missing?

I just read Jeff Feinman’s report in SDTimes (http://www.sdtimes.com/link/33404). It is all nice, but in my view it is a colorful account of the visible tip of the RIA iceberg that ignores the submerged bulk of corporate applications. True, R.J. Owen is quoted on JavaFX’s better fit for the corporate environment, yet I did not find any consideration in this report to the main hurdles of Enterprise Rich Internet Applications, which relate to the coupling between the Client and Server tiers of a RIA. In defense of Jeff, I could say that indeed none of the 3 platforms (Adobe Flex, Microsoft Silverlight and JavaFX) deal with that challenge – all of them address only the Client tier. But then, when the subject is the RIA Market, I think that one should address all the aspects of RIA’s and not just the Client tier platforms.

Compared to the present standard of Enterprise Applications (Client/Server with a fat Client), RIA’s have very compelling advantages for Enterprises; they run anywhere – remote or Local, support On-premises and Off-premises deployment, offer a rich interactive user experience and a native platform look & feel without the hassle of a local fat client, reduce the cost of ownership, improved scalability and tighten security.

But in order to make these advantages usable, RIA platforms need to take the sting out and resolve the coupling management. A Client-Server application involves a fairly simple architecture, relying upon a permanent connection between the Server and the Client. With a tightly coupled design, there is no need to explicitly manage or preserve various logic states. Conversely, web applications, which centralize their processing in the Server, leave the Client essentially decoupled, or loosely coupled. As long as web applications feature short and simple logic processes, and a limited richness of interactivity, they can be usually implemented with standard Web architectures and simple session management. We start seeing even LAN interaction styles with Ajax, such as Google with the ‘Google Suggest’ function that brings up popular search terms as you type in every successive letter of your search word into the search field.

However, broadband internet is not sufficient for tightly coupled business applications having tens of interactive fields per screen, typical to Enterprise Applications. To get around this limitation RIA’s have to partition processing between Server and Client.  So you end up working with two physically separate and logically dependent logic sets – running in tandem on both the Client and the Server. While smarter, the Client now is required to play in concert with the Server, and to keep the session coherent requires sophisticated state and session management. So while traditional Client Server apps only needed the skills of a business developer, if you want to develop a non-hosted RIA using a Client-side platform you need to add sophisticated system programming skills to your team, adding considerably to the complexity and risk of the solution – a painful and costly sting.

There is now a new breed of end-to-end platforms that can provide a comprehensive answer to this RIA Iceberg challenge, mostly targeted at the XaaS model. Forrester recently covered the PaaS market in its report “Platform-As-A-Service Is Here: How To Sift Through The Options”, and Gartner published a similar report titled “Application Infrastructure for Cloud Computing: An Emerging Market”. One of the most popular platforms that take out the sting of Enterprise RIA’s is Force.com, but it is currently available only as a hosted platform. An alternative, which is available also as on-site (the venerable “Private Cloud”) is Magic Software’s uniPaaS, which can be used either on-site or as a hosted Platform-as-a-Service (PaaS), providing the choice “to be or not to be” in the Cloud. The key difference to Client tier platforms such as JavaFX is that this type of platforms provide all the parts of the solution – including the hidden part of the ‘iceberg’ – without needing you to develop it separately. Hence ‘end to end’.  All that’s really needed is to describe the application’s business logic and design the compelling user interface, and the platform then takes care of the rest.

 

Differentiating Situational and Systematic Applications

I think that there is not sufficient distinction in the industry between Situational Applications and more persistent solutions (how would you call that type of apps? Systematic? Core? Persistent?).

I have witnessed the deep frustrations of IT managers who adopted a Situational Apps tool thinking it could be used for any type of solution, and running into walls late in projects, ending up with unsatisfactory solutions both from functional and technical aspects.

That does not mean that Situational is not good – just that one should use it for what it is meant for.

The story (rather history) of Magic Software is quite enlightening in this respect. When we first launched Magic II in the mid-80’s, we were in the midst of the first wave of the situational buzz with data oriented application tools such as Framework, dBase, etc… Magic II innovated by offering a metadata driven environment, which was much easier to master for business professionals than code driven tools. So we happily promoted it to ISV’s and Enterprises, with a silver bullet message and doing away with waterfall or other development models. It worked great for a while, but as applications reached the production stage their design flaws became apparent. I recall being summoned to a large pharma enterprise by the head of their clinical tests department, because the application he proudly developed was gradually slowing down to a halt. It did not take long to discover that the data structure was so convoluted, that some lookups ended up sequentially scanning tens of thousands of records.

The majority of the PaaS offerings today are for Situational Applications. That is quite understandable, since it take a significant effort and time to develop PaaS with highly granular widgets that enable the same power of implementation as coded environments. The danger though, is that the hype and buzz are so high and blinding that many prospects to not perceive the limitations (ending up as I described above).

So my call to action is to offer more down to earth information and transparency about what a technology is good for, so that those in need for situational tools are not overwhelmed with complexity and those looking for persistent and core solutions do not try to implement them on straws.