Posts Tagged ‘SaaS’

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/


Read Full Post »

JP Morgenthal wrote a great article on software architecture – SOA Viewpiont: The Software Architect’s Dilemma. Yes, it was written in May 2008, so it is a bit dated, but it is still relevant given all the recent Blog/Twitter discussions about SOA’s death.

In Morgenthal’s article, he states that, “… until the IT industry recognizes software architecture in the same way as construction recognizes building architecture, that software architects will forever be frustrated by their situations.” I agree with the basis of his arguement – who would disagree with the notion that you need to value architecture? Architecture is the foundation for any and all sound engineering activities, and Architects are the primary stakeholders responsible.

But as a community, what we need to really think about now is how to address the long running problem of undervaluing architecture, specifically, and engineering, in general. Not valuing something, especially as significant as architecture, is a complex cognitive problem (often assessed as a psychosis) that often has many causal factors, some of which are very very hard to address. For example, most CEOs are revenue/margin facing, channeling most of their energy and interest into sales, and some marketing (but very little). They often leave the techie stuff up to the techies; so treating Architecture as a first class organizational activity is unheard of at their level. However, these same CEOs often micromanage the day-to-day sales architecture of their own organization. Do you see the disparity?

(Soapbox Moment) As a nation, we have lost the science and engineering basis that is needed by a leader in a knowledge-oriented world (see Dean Kamen – USFirst.org). Until we understand and deal with this disparity, not only will we continue to suffer as a nation, we will continue to fail at delivering the architectural foundations, like SOA, needed to build sustainable solutions.

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 »