tag:blogger.com,1999:blog-356516183452551110.post7094290253214542079..comments2024-03-14T22:05:51.185-07:00Comments on Software Engineering: Architectural Considerations for Multi-Tenancy – Part 2Raja Bavanihttp://www.blogger.com/profile/03107697584076683320noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-356516183452551110.post-83285695979711066862014-09-30T06:27:41.738-07:002014-09-30T06:27:41.738-07:00Thanks Manikandan, These are two good additions t...Thanks Manikandan, These are two good additions to the list shared in part-1 of this post. Thanks for sharing! Appreciate it.<br />Raja Bavanihttps://www.blogger.com/profile/03107697584076683320noreply@blogger.comtag:blogger.com,1999:blog-356516183452551110.post-71150828283887876742014-09-30T03:46:02.675-07:002014-09-30T03:46:02.675-07:00Hi Raja,
A very thoughtful, informative article. ...Hi Raja,<br /><br />A very thoughtful, informative article. I do have experience in do a pilot for SaaS enabling a Legacy J2E Hospital Information Application. <br /><br />As part of SaaS enablement, apart from what ever you have listed in your part-1 series, I believe a comphrensive business case is required, in case if you know the cost of ownership for the legacy application, it will be easy to see the TCO difference between a software license model and a service based pay-per-use model<br /><br />One more point, is to have your sales team concurrence on how are they going to position or segment this product since the current existing business for the legacy application can be big so you don't want to position your new "on demand" service as a direct competition to your exisiting licensing product. So your "as a Service" model can start with minimum viable features and customers may need to buy full fledged software for getting a bigger feature list.Anonymoushttps://www.blogger.com/profile/11912001322052133833noreply@blogger.com