Feeds:
Posts
Comments

Archive for the ‘SaaS’ Category

This week, the top 30 US and international cyber security organizations (e.g., Red Hat, EMC, Apple, MSFT, NSA, etc.) jointly released the consensus list of the 25 most dangerous programming errors that lead to security bugs and that enable cyber espionage and cyber crime. What this joint team found was that most of these error were NOT well understood by programmers, across all types of organizations (big/small, insource/outsource, etc.). Equally important is that these errors are all appropriate for both SOA and SaaS developmental activities.

I think it important for use to share these findings with your development teams, assess our current developmental activities, and educate your teams on the principles found in this study. Also, we each have an have an opportunity to show some thought leadership and participate in a technical area that is not currently owned by too many organization. Below I have the link to SANS (information security authority) which not only contains the top 25 programming errors, but also an excellent set of resources (from Mitre) to help identify and address these issues.

Findings Ref: http://www.sans.org/top25errors/

Advertisements

Read Full Post »

For those that did not make it to this year’s SIIA conference in San Jose, CA, here is a link to the SaaS Integration panel discussio:

SaaS Integration: the Whole is More than the Sum of the Parts

Read Full Post »

Daniil Fishteyn, CTO of WebApps Inc., discusses multi-tenancy in his recent white paper produced for the SIIA OnDemand Conference 2008. Fishteyn makes the observation that since few standards have been established for multi-tenant application elivery or operational goverance, the suitability of SaaS in support of mission critical business activities needs to be explored.

Read Full Post »

The SAAS Industry Will Die…

Juan Carlos Perez raises some vary valid issues through the recent article “Study: Clear Strategy Key for SaaS E-Commerce Success.” In order for the industry to survive, we need a new way of evaluating these companies – SAAS 70.

SAAS 70 would be the equivalent of SAS 70 (Statement on Auditing Standards No. 70) for the SaaS industry that would provide a standard approach to evaluating this new type of service-oriented company. While SAS 70 defines the professional standards used by a service auditor to assess the internal controls of a service organization, this SAAS 70 auditing statement would address the critical aspect of SaaS that are important to subscribers – Software Development, Operations, and Continuity of Operations.

SaaS is more than just adding a few new features to existing set of applications (e.g., multi-tendency). SaaS is about software (e.g., continuous integration, compatibility control, etc.), operations (e.g., performance, scalability), and continuity of operations (e.g., process and data availability and reliability – MTTF and MTTDL, respectively). Existing evaluation techniques are inadequate for assessing these business characteristics under the SaaS paradigm.

So, in order to evaluate SaaS providers, subscribers need to look from the outside-in; that is, starting with a view of how continuity of operational activities are achieved first. For example, if a subscriber is from a regulated industry that requires 1, 7, and/or 14 year information retention policies (e.g., healthcare, high education, financial, etc.), then understanding how SaaS providers protect data for that same period of time is extremely important – just ask any public company CEO/CFO who has to sign their name on the 10K/Q.

As an industry we need to step up and deal with this issue soon or face the real possibility of failing within the next few years. Let’s not wait for the equivalent of the Fen-Phen lawsuits to hit before we take the assessment actions we know we need today.

Read Full Post »

While it is true that integrating best of breed SaaS solutions can be problematic, the conventional belief that SOA, Webservices, pre-integrated adaptors, or even specialize middleware frameworks can solve the wide array of integration challenges is often not as true. So, knowing which side the problem is on make life a whole lot easier when integrating SaaS into on premise solutions.

But before we dive into that, lets go back a bit to compare and contrast a modern integration strategy with its counter part from the 1990s: SOA and CORBA. The question we want to briefly explore is, “Why did SOA succeed where CORBA did not?” Both are an integration strategy built on various types of services. Both are designed for highly distributed systems. Both have some level of message based payload used to transmit key process content. Yet, CORBA never really got off the ground and has virtually died, while SOA is being adopted at a wildfire pace. Why?

A significant part of the answer can be found in the fact that SOA is, for the most part, based on a set of standards. Take web services (as subset of SOA), for example, the transmission protocol is http, the data payload is xml wrapped in SOAP, the service contract is defined through WSDL, and services can be found through UDDI. All standards that have helped neutralize vendor variability often seen in technology driven phenomenon. CORBA, as good or bad as it was, never had this level of standards support or adoption.We now face a similar pivotal challenge with it comes to SaaS business process integration.

The real business value in most systems is not in its discrete services, but in the choreography of the services to support business value generation. Think about it, is there real business value in submitting an expense to an expense report service. No. The value is having an expense process solution that incorporates all end user interactions while applying company specific business rules. Here lays the crux of the problem – services are not business processes and it is the business process that needs integration. Translation – “it’s the process stupid, not the service.”

Services development has been the focus of most, if not all, of the most activity surrounding modern integration activities. They are easily developed and can be readily exposed (through SOA, WS, API, etc.), but our ability to integrate business processes has largely not been addressed, with one exception – BPEL (Business Process Execution Language). Without a strong process integration standard that is widely adopted, like BPEL, integration between best of breed SaaS solutions and enterprise application will continue to be problematic and failure to achieve real business value will most likely be placed at SaaS’s doorstep.

So, you don’t think it can happen to you! Take the case of a large ERP (independent software vendor) company that develops ERP systems (e.g., financial aid, student admin, etc.) for the higher education community. They created a SaaS solution based on the main financial aide product line and exposed the services that composed their proprietary financial aide process as web services. One university used those discrete services to integrate the SaaS offering with their on premise systems, applying their own financial aide business process rules instead of those within the SaaS financial aide system. The resulting loan package was invalidate even though each used service was properly used (technically called – service transitivity). It took a while to figure out and was eventually corrected, but the down time cause a lot of client dissatisfaction and necessary support costs.

So, when dealing with the integration of SaaS to other enterprise solutions (on premise or otherwise), pay more attention to the interaction of the business processes than those of just the services. SOA, Webservices, pre-integrated adaptors, and even specialize middleware frameworks play a very important role in solving the SaaS to enterprise integration puzzle, but they only get you part of the way there. Spend equal time and effort in dealing with your business processes (e.g., BPEL) so that true business value can be sustained even when using best of breed SaaS solutions.

Read Full Post »

Todd Gardner (CEO of SaaS Capital) and I are conducting webinar on SaaS called: Turning Code in Cash: Best Practices for Enabling SaaS Delivery. Topics to be discussed include:

• Increasing the scalability and reliability of your SaaS application
• Designing for Operations and Continuity of Operations
• The SaaS Application Maturity Model
• Cash requirements for SaaS businesses
• Funding alternatives during capital-intensive growth periods

Please join us, if you can, and I will be posting the presentation later this week for those that cannot.

Read Full Post »

SaaS: One View of Its Future

Nobody ever knows for certain what the future holds, but if revenue potential is any indicator of what could be in store, then for many software companies the future is somewhere in the Software as a Service (SaaS) business. Developing solutions for SaaS-based businesses is very interesting, but many in industry don’t understand how it differs from traditional software development and why these differences are of value to the end users.

SaaS-based solutions are composed of three core components: commercial-grade software products, operations, and continuity of operations. In addition to creating and maintaining effective products (which is the heart of the business), SaaS-oriented businesses need efficient operations to realize the value of the development investment. Companies need to efficiently operate the software they build; in essence, “eat their own dog food.” It is not enough for the development team to just produce a product that has good enough features and acceptable performance, scalability, and reliability (PSR) characteristics; it needs to be operable with the defined business parameters of the company – they need to be Designed for Operability. This is a huge difference between an independent software vendor (ISV) and a SaaS-oriented solution provider.

But it is in the continuity of operations (COOP) that real differences emerge between ISV and SaaS. COOP is concerned with making sure that the essential business functions are performed in the face of catastrophic events. COOP deals with both preventing disruptions from happening and responding to disruptive events when they occur. Terms like Recovery Time Objective (RTO) and Recover Point Objective (RPO) are commonplace in a COOP team. Capabilities like disk-to-disk-to-disk replication and synchronous/asynchronous replications are enablers used to mitigate the disruptive impact of a disaster. From a product development perspective it is therefore not enough to design around feature or technical concepts, like SOA, but instead one needs to also Design for COOP and implement that design.

The SaaS-oriented business is also different from an execution point of view. In traditional ISV operations, development operates incrementally to get the product right, while the SaaS-oriented business needs to execute so they never get it wrong. In today’s market, it is an acceptable practice to release products that are both incomplete and with known types of bugs (none critical). Industry has developed a whole maintenance and sustenance program around the firm knowledge that they will need to fix products post release and make them better over time. Right? However, when the revenue of your company flows directly through the operational product you built, this traditional point of view can be devastating.

So the SaaS is a pretty unique market, it not only needs to have capabilities that can produce great products on time and within budget, but additional operational capacity that enables organizations to effectively use those products without fear of end-user disruption. From my perspective, this is a pretty significant difference and those companies that get it right will differentiate themselves above those that just think like traditional developers.

Read Full Post »