Providing SaaS solutions on a shoe string budget

These days there is lot of buzz around Software as a Service (SaaS), especially solutions targeting small and medium businesses. As terms like scalability, reliability, availability are all very important for providing these services, I started thinking on data center approaches for start ups to provide SaaS solution and came up with the following alternatives:

1. Procure all the hardware - install, configure and deploy the solution. A pretty expensive undertaking that requires a lot of $$$ - plus additional $$$ for disaster recovery . One alternative would be to rent servers from providers like Verio, Yahoo and GoDaddy but this still requires substantial investment.
   
2. Leverage SaaS platforms provided by companies such as SalesForce.com or Coghead which are pretty reasonable and they do have decent partner and developer program. However, the drawback to this approach is that the solution would not be portable and you are basically tied to their customer base and pricing bundles.
3. Get a web hosting solution from a solution provider like Yahoo! (cost approximately $12/month) which includes mySQL, PHP and Perl. Leverage them to develop the business logic and expose them as services. Leverage the social networks platforms like Facebook to develop the User Interaction and release it with limited free features. A great, cheap way to enter the SaaS market on a shoestring budget and once successful - go ahead with alternative 1.
   

Just a thought for those interested in entering the SaaS market on a shoestring budget.

- Yogish

Key Learnings : The End of the Application

This is a blog post in response to Todd Biske's posting on "The End of the Application" which can be found at the following URL.
http://www.biske.com/blog/?p=347

******************************************************************************
I am in complete agreement with you Todd, about needing a retirement plan for the term "application"!!! I share your sentiment about how this ubiquitous term reflects not only the siloed solution that gets built but also in how this term influences the way in which the business need is translated into requirements. Case in point is the way in which I have heard business analysts phrase their questions to the end-user. For example, "How do you expect to act on the information the application provides?" as opposed to asking "How do you or your user community make decisions based on this information?" OR "What is the business context (business rules, policies,regulations etc.) that influence the information?". The business analysts sould divorce themselves from thinking about the application as the "sole repository" of the information and it's current limitations. Analyzing the business user needs and the decision making process might help them discover that these business rules may have already been implemented elsewhere and that the "application" is but one component needed in delivering the targeted business capability. Sadly,this is not the case.


Part of the reason for gravitating toward point solutions and monolithic deployments is the sense of control the solution owner has on the entire solution stack and the confidence factor of knowing that a customized deployment has a better chance of meeting the response time SLAs. It is my hope that the availability of robust standards based deployment platforms may help resolve some of these latent fears. The key however is to recognize that the usage of the term application does influence the final implementation of the solution. Given this, there is ample justification for doing away with the term "application" as it may be too limiting in the realm of today's highly interconnected enterprise.

Doing this may lead to the required behavior change that is needed to move away from the creation of monolithic applications. As suggested by you Todd we may need to be more conscious of the term we use and this could be a simple matter of using a prefix to the term application or it may be that we have to throw the term away altogether. I propose using a prefix of "composite" to qualify the term application to get this desired change in behavior!!


The term application should be semantically equivalent to "applying" a
unique business context to the usage of a common asset such as a business service, legacy system or a business process. This "application" (note,the verb) of value-added business context is focused on delivering a crucial business behavior that offers competitive advantage to the enterprise. With that definition in mind, the term "application" may get a lease for life when used within the purview of the concept of "composite application" that suggests "distributed solution assembly" instead of "monolithic solution creation". Composite applications are mechanisms that help deliver novel business capabilities that are typically translated to"novel" assembly of reusable business services where by the composite application layer performs business context value-addition.


This assembly of business services within a composite application (as opposed to the creation of a monolithic application) enables the enterprise to realize "speed to market" gains from SOA. It also enables an enterprise to move to a model where the enterprise obtains base business services (off the shelf or SaaS style) and uses the composite application layer to apply the enterprise specific business context with the idea of offering distinct flavors of service offerings; thus moving away from the "creation" of solutions to "provisioning" of solutions. (It is worth noting that composite applications are not just deployed in the business layer but also
in the presentation layer in the form of Web 2.0 style mashups.) Finally, I feel that the only way we can move away from the mode of "monolithic point solutioning" to a mode of "assembling solutions" is by making the move to the concept of "composite application" as it breaks the existings emantics associated with the term "application". Following this mindset switch we may be able to completely replace this term as knowledge workers develop a comfort level in both the efficacy of "assembling solutions" at the same time that the vendors build up deployment platforms to help IT meet the stringent SLA needs that are demanded by the business.
***********************************************************************************

Key Learnings: Drawing parallals between Design Patterns and the priniciples of SOA

In looking through some of the Object Oriented Design Patterns, I found a curious parallal between the goals of some of the "Structural Patterns" and "Creational Patterns" and those of SOA.

The following are the two key principles that are most striking:
Principle 1: provide a clean interface or an entry point and hide all of the details from the caller
Principle 2: provide a layer of indirection between the interface and that of the implementation

It is interesting to see how these "design level" goals re-appear in the realm of architecture with changes only to the scale of applicability.

Principle 1 is supported by design patterns such as Facade, Abstract Factory, Builder and the Factory. Facade hides the behavioral details of the implementation while the others hide details of the details of the creation of a resource or assembly of a resource as in the case of "Builder".

Priniciple 2 is supported by the Bridge pattern that allows the plugging and replacing of any implementation long as the interface is supported.

The idea is not to arrive at a comprehensive mapping of the principles and design patterns but just to do enough to lend support for the core theme being presented here. This leads to only one conclusion, SOA does not preclude the use of good OOAD techniques. SOA just takes these concepts further into the realm of business architecture and business analysis to insure reusability and enterprise wide applicability of the IT asset, in this case a "service". SOA also has been lent support by the standardization of platform agnostic protocols and message model (such as SOAP/ HTTP) and the use of canonical business models (such as XML Schema backed XML).

Your comments are invaluable.
surekha -

Is SaaS ready for prime time?

One of the questions that keeps coming up in my conversations with my peers is whether SaaS is ready for prime time? My response to this is that yes!, especially for small or medium size company. I would not hesitate to recommend SaaS solutions such as NetSuite or SalesForce.com to small and medium size business.

As a small business, one may start with solutions provided by Intuit (either on a desktop or SaaS) and as they grow out of it - NetSuite may be a better choice, especially as they provide and end-to-end-solution.

SalesForce.com's advantage is their primary focus on CRM - critical to small business and their AppExchange platform. Based on my initial assessment - I do like it. The jury is still out on whether 3rd party shall develop applications on this platform. If they are successful in attracting the development community - they should be able to go head-on-head with NetSuite - will be interesting to watch.

As for SAP and Oracle on Demand - have not reviewed their solutions as yet.

A web site is key to small business and I do like the Yahoo! Site Solution - easy for anyone to use and did redeploy SOABlueprint using this solution. It just took me a few hours - which previously had taken be over a week to redesign and deploy new content. The only drawback to this solution is that it restricts me from integrating it with Google Analytics or Google Ads. Hope they open it up soon.

Google Sites also provides an alternative and have used it to create the a Collaborative Wiki for SUIT. Google enables small business not only creating a web site using web pages, it integrates Google Apps and the Wiki (JotSpot Acquisition - discussion forum is not yet available). However, once again like Yahoo! they do not allow Java Scripts to be embedded in their pages - once again I am locked out from integrating Google Analytics, Google Ads. and Grand Central - tools that I would like to leverage on all my sites, not just my blog.

In short - SaaS is ready for prime time, especially for small and medium business. However, these companies still need to put in a lot more effort in getting the word out to the market.

Extending the use of Service Enabled Interfaces for dealing with Business Events

Typically Business Services are considered to be invoked in a synchronous request-response mode. Business Applications are supposedly called into action by human actors who leverage user interfaces. On the other hand, Business Processes are typically assumed to be triggered by Business Events.

However, it is possible to extend the use of Business Services and/or Business Applications to deal with Business Events. This enables the reuse of existing business logic and business rules in order to deal with new buisness interactions which are introduced into the ecosystem without needing to undertake a large service implementation effort.

For the purpose of this discussion Business Services, Business Processes and Business Applications will collectively be named as Event Response Interfaces. Business Events can be routed to the receipient Event Respsonse Interfaces by an ESB or a Message Hub. Business Events may also be sent to a Complex Event Processing Engine for aggregating, filtering or de-duping business events prior to routing them to the apporpriate Event Response Interfaces. Having said that, how does one extend existing Service Enabled Interfaces to trigger them asynchronously?

Architecturally, adding a Message Listener that in turn calls the Service Interface (such as seen in a Service Activator JEE pattern) or leveraging a Service Mediator (such as an ESB or a Message Hub) can allow Business Events to invoke Business Services or Business Applications outside of their regular request-response mode of interaction. The use of this simple architectural strategy allows Business Events to be processed by existing well tested Business Services or Business Applications.

One additional point to keep in mind in extending the interaction context from synchronous mode to that of an asynchronous mode is with regards to dealing with business exceptions, faults and business responses. In a synchrounous communication mode both of these are returned to the invoker of the business service or the business application. In an asynchrounous mode there is a disjointed execution context where in the invoker is not blocking on the call and waiting for execution control to be returned. The execution path may or may not be re-established.

To deal with this asynchrounous communication model the service response and faults may either be logged in a common repository or may be returned back to the invoker by the service mediator. The service mediator may re-establish the execution path with the invoker. The service mediator such as the ESB may refer to the Registry to find the originator or may leverage the correlation identifier and originator address in the payload (a provision made by the WS-Addressing spec. via the use of wsa:From metadata element).

Regardless of which architecture component is used i.e. an ESB, a message hub or a message listerner that intercepts the Event Response Interface the result is the reuse of the service behavior. In addition to reusing the business service applying this simple service extension technique also enables leveraging existing investments in infrastructure components such as the ESB or message hub thus helping achieve business agility.

Please provide me with feedback as to whether or not you have leveraged existing IT service assets to introduce new communications pathways.

surekha -

Invitation to joing the Strategic Use of IT (SUIT) Group

The SOA Practitioners first time got together in August 2005 to share out best practices, key learnings, organizations and governance approaches to Services-Oriented Architecture. Even though SOA is the current hype, the SOA Practitioners believe that the basic principles of this architecture approach will last with the primary objective being the Strategic Use of Information Technology (SUIT). In order to facilitate collaboration between the various teams we have established an Linked In group and leveraging Google Apps to facilitate collaboration among the practitioners.

All Business and IT Practitioners are invited to join the SUIT Group on LinkedIn. Joining this group will allow you to find and contact other SUIT members on LinkedIn as well collaborate using the Google Apps and Sites (Wiki). The goal of this group is to help members:

• Network with other SUIT Practitioners
  
• Share out best practices, key learning, bounce ideas, etc.
  
• Collaborate using Google Apps & Sites

Click here for details on how to join this group.

Business Architecture Dialogue

I will be participating in SOA-Consortium conference being held in Washington DC from March 12-13. One of the main topic I will be focusing on is "Business Architecture". As a result of EA 2010 working group, we have identified Business Architecture as an important aspect of Enterprise Architecture. One of the problems is that there is no clear understanding of what the BA is and how an enterprise should go about creating one.

Surekha Durvasula and myself will be leading a discussion panel to get particpants to talk about their understanding or lack of understanding of BA. Being in Washington, I am sure the dialogue will involve public sector's take on this topic. It will be interesting to see how some of these concepts translate in a public sector settings.

Will let you know how it turned out.

Ashok