The CIO's dilemma about SaaS and Cloud Computing.

Thanks to Todd Bisk's blog on Software as a Cloud vs Software as a Services I got the opportunity to listen to the Churchill Club podcast from ZDNet recording of a debate between Marc Benioff, CEO of Salesforce.com, and SAP Chairman Hasso Plattner. It was an interesting debate where Marc was positioning AppExchange as the next generation platform (for SaaS) where as Hasso positioned Business by Design more of a cloud computing platform - initially targeting small and medium business.

As CIO's starting hearing about these industry trends it creates a dilemma for them. Where should they use which solutions. Following is my take on the topic:

As per my earlier post Is SaaS Ready for Prime time? I would recommend that CIO's adopt SaaS solution for non-critical and/or non-differentiation business solutions such as Sales Force Automation, Financial Applications and HR applications. As all the SaaS platform are proprietary I would customize the business process for these solution and make sure not to move/develop and key customer differentiation solutions to these platforms. Not because of security concerns or any of the 'ities. Primarily to avoid lock-in to a particular vendor.

As for cloud computing - not sure I would adopt this as a large enterprise. As a small business, I would be tempted - but isn't it cheaper to rent entire servers on a month-to-month basis from hosting providers like Yahoo!, Verio or GoDaddy? I understand that some very large companies like Google, Yahoo! and eBay leverage such an architecture. I do not have anything against this approach and would love to leverage such a model. However, I would have to agree with Hasso - this is at least 5 years away. To me cloud computing means - I should be able to model my business solutions based on standards such as MDA, BPMN, UML, BPEL, XPDL and SCA using a single tool (don't care if the tool is proprietary, Eclipse or Netbeans). Once the business solution is modeled, I would like to analyze and deploy the business solution (potentially a composite application) to in-house data center (servers or appliances), SaaS provider and a cloud computing provider. In short - I buy into Hasso's business and technology model for Business by Design and their challenge is whether they would be able to pull it off.

Sounds confusing? Yes! it would be - especially if you assume that all this runs on a middle ware. As the technology and standards mature - I expect most (if not all) of the middle ware capabilities to embedded into the Operating System.

- Yogish Pai

Introduction to Services-Oriented Operating Systems

IT Organizations today need to procure a lot of additional infrastructure components (hardware and software) to adopt SOA. This increases both the IT capital expenditure as well as operating cost in terms of head count required to support the infrastructure. There should be a simpler way. Wouldn't it be easier to just deploy a single software (an OS???) on all the hardware and configure (deploy) solutions on them on as needed basis?

As more and more of middleware functionality is going into a chip and network card - the time has come to converge both the OS and the middleware into one single engine.

Foundation Components:

Workflow: A basic workflow engine that could be leveraged/expanded to execute business logic, user interaction, etc.

Security: Basic security capabilities based on industry standards.

Transformations: Provide transformation services and leverage hardware wherever appropriate.

Discovery: Dynamic discovery of other nodes, reference services, resources, etc. Supports standards such as WS-Discovery, jxta, Jini, UPnP and other P2P discovery capabilities.

Management: Enable remote management of all foundation services as well as other components and solutions.

Monitoring: Inbuilt configurable monitoring agent to not just monitor the OS but also act as a sensor on the network.

Bindings: Decouple all bindings from all services (similar to Services Component Architecture - SCA) and support protocols such as WS, HTTP, JMS, RMI, CORBA and SIP.

Service Enables: Inbuilt component that invokes the services both local and remote services.

Virtualization: Enables virtualization of the OS on an existing technologies such as VMWare and Xen or on baremetal.

Services-Oriented/OS

Following is an high-level overview on the SO/OS.

The SO/SO consists of the three layers and is entirely based on the principles of Model Driven Architecture (MDA).

Domain Layer: Also referred to as the data layer - a combination of the data layer provided by any Application Server as well as Data aggregation capability provide by EII tools. By default it comes with a Cache which could extended to support distributed caches (such as javaspaces). The objectives is to change the model to get all application to leverage an entity (object model) to perform transaction. Basically develop a data grid and let it figure out how to get and update the data at the source. The service developer just deals with the business objectives/entities. In addition, the domain layer could leverage the workflow foundation component to include some business logic or flow.

Business Logic: Consists of three major functionality. The extend the workflow to execute business logic based on standards such as BPEL and XPDL. Business rules would that enables business owners to change rules without having to change code. In addition, this rules engine could be leveraged to apply security and monitoring policies. The third component is the event server that included Complex Event Processing (CEP).

Presentation Layer: Consists of the following components.

Service Broker/Router: Listens to all events and invokes a local or remote service (leverages Service Enabler Foundation) and if it is not found routes the service (either pass through or redirect) to the appropriate destination (leverage Discovery foundation).

Workflow: Leverage foundation component to provide User Interaction.

Presentation: Includes multi-channel and branding support and support all major presentation technologies.

SO/OS Management

Following is brief description of the management approach for SO/OS

First there is a need for a real-time service repository (RTSR) for managing the run-time. No! this is not the same as Service Registry (based on UDDI). Potentially the CMDB could be modified to provide this function.

All applications shall be assembled (based on SCA standards) and target the destination nodes. The destination nodes would have the same SO/OS installed on all of them and could be fined tuned (configured - based on quota or some other policy) to run only some of the components. Every time a node with SO/OS comes up - it is registered with the RTSR. All applications should be provisioned to the destination node and as all the application logic is stored in meta-data - one could potentially leverage the "Service Provisioning ML" standard for provisioning (currently used only for provisioning security policies). As and when the run-time node runs out of capacity, the RTSR could provision another node to pick up the load (dynamic configuration).

The SO/SO must support SCA and leverage the dynamic foundation component to dynamically discover and identify the EPR for remote services.

This are just some of my very preliminary thoughts and shall expand on them if there seems to be interest in the community.

- Yogish Pai

End of Application???

One of the advantage of co-blogging on the same site is that you can get two view on the same topic at the same blog :). I did review both Todd's Blog on End of Applications as well as Surekha's response on the same topic. In principle I agree that it would be great to get rid of the word or term "Application" - however in my mind this would not be practical because this word is very widely used in the Business Community.

Following is something that has worked for me in the past. Business would refer to Siebel or PeopleSoft application whenever they meant CRM or Order Management. With the help from the LOB-IT (and the decision makers from Business Operations) we were able to get business to start referring to them as Forecasting Application, Order Management application and Lead Scoring Application. It took over a year to change to get business to refer to the business process as applications - instead of getting rid of the term applications.

As a true EA - in all my presentation, budgeting cycle and various leadership team meeting with business - I referred to them as "Business Solution" with no success. Business still called them "Applications". Finally, it dawned on me - it is equivalent to the common vocabulary such as we drive on a parkway and park on a driveway- we most probably will not be able to change this to "we drive on a driveway and park on a parkway" . Similarly I do not believe we can get rid of the term "Applications" (and believe me I did try my best to get rid of it :) ).

Just my thoughts on this topic.

- Yogish

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.