SAS 70 Type II Is Not Enough

It's interesting how so many cloud providers point to their SAS 70 Type II attestation. Having been through the process of a SAS 70 Type II audit for a SaaS finanical services firm I'll point out the major gaps that providers do not make clear about a SAS 70 attestation.

• A SAS 70 Type II attestation is about financial controls, not operations, not security. Therefore if something does not impact the finances of a company it is considered out of bounds for the audit. Remember the AICPA (American Institute of Certified Public Accountants) governs the SAS70 auditing standard. I respect accountants and auditors but I have yet to find one who I can't make their head spin with technobabble.
• There is no standard for the contents of the attestation. The SAS 70 contains self reported financial controls. Therefore each company, by shopping for an auditor, can intentionally omit germane information and still have an attested report.
• The attestation report is not available to non-customers by rule. If it is shared with a customer it is a violation and that alone should make someone wonder. Even as a customer there is often a significant cost associated with getting a copy of a SAS 70 audit report (in the tens of thousands of dollars based on my experience).
• The attested report simply validates that the organizations does what it says it does. During the audit it is possible to obfuscate issues because the audits do not contain a significant amount of process execution observation.

A more proper standard given the significant concern over cloud security is ISO 27001 focused on information security. And it is my understanding from friends in the audit industry better standards and guidance are coming.

Demand more; don't be satisfied with a SAS 70 Type II audit. And if you can't get your hands on it your missing nothing.

A Legacy Laced Cloud

The times they are a changing! And with all of the external forces driving change into organizations, plenty of internal forces are ebbing away at the status quo. I wonder is cloud the impetus for change or the reaction to the need for change? I think the answer is both, but the former is a tactical answer while the latter is a strategic answer.

Cloud helps companies in dramatic ways as proven by early adopters. The primary use case for cloud technology deployment to date has been to reduce costs within IT. A second emerging use case is the time to market benefit as cloud resources are often easier to procure, configure, and/or build solutions atop. However in the adoption of cloud we need to have a pronounced, intentional plan, especially when it comes to legacy applications.

I have witnessed situations where dropping an application to a cloud environment increases risk more than value. Not all applications benefit from virtualization: stable applications with little fluctuation in usage of resources often look identical with the single benefit being the sharing of unused resources (which may be enough of a benefit to argue for cloud). However many of the open questions when moving legacy applications into the cloud (or any alternate platform) include:

• software library support
• level of coupling (operating system, libraries, other applications, utilities, etc.)
• component versioning
• development, test, qa, and staging environment setup and certification
• test cases and automated testing
• testing of the application and its associated components and certification
• migration to production
• training of developers and testers
• update of disaster recovery plans
• update of systems management services (monitoring, troubleshooting, backups, etc.)

This is the easy short list and assumes no change in functionality!

Finally lets not forget the law of unintended consequences. Something will go wrong as a result of the change that was not forecasted and is a direct result of the new architecture.

Minimizing these risks is possible through a methodical, structured migration program governed by the following concepts:

• Establish a framework - define an application framework to align redevelopment and future development with the growing capabilities of a cloud, even if only a portion of the cloud functionality is available.
• Challenge conventional thinking - there is no reason to assume clouds cannot benefit siloed applications, mainframes cannot participate in a cloud, CICS applications cannot be executed in a cloud, or that the end game is even cloud (it should be delivered value).
• Crawl, walk, run - learn from the first efforts and cascade that learning into following efforts until an optimization loop becomes part of the DNA of migration projects.
• Components or Containers - for each application determine whether its better to componentize, optimize the application for the new environment adopting a SOA model, or containeraize and keep the application isolated as a whole solution perhaps using web services to map inputs and outputs extending the reach of the application. In an earlier blog post I provide four options to handle legacy applications.
• The learning curve - architects, designers, developers, and testers will all need to relearn significant parts of their job. If internal development is a core need make sure the necessary skills are identified, quantified and present within the teams.

Legacy and cloud can coexist in many forms. The reality is many applications do not deliver enough value to justify their migration to a cloud environment. The goal should be to maximize the value delivered which means applying cloud capabilities where there is a business case to do so.

The Dissolution of IT

This post is based on one of the half dozen white papers I've written in my career which were too "out there" to be published. I wrote this one in 2007 about the time I left Diamond Management & Technology Consultants for what became a failed financial services SaaS startup. You have been forwarned!

In 2004 I went through the IBM certification process for Enterprise Architecture emerging as a certified Senior Enterprise Architect. Starting in 2001 I was pushing my architecture envelope to understand as much as I could about the business. I started questioning my mentor father about his experiences including his 30+ year history in Supply Chain Management. I started learning everything I could about cool sounding ERP processes: order to cash, quote to cash, and procure to pay. As I pushed my boundaries I found companies were doing the same; assigning senior business analysts as the liaisons to IT. I worked with many in partnership asking them to teach me about the business while I would deepen their understanding of IT. Each of these business experts I found had a common trait: all had an IT background.

As I applied my business knowledge I started getting accolades from clients about the robustness of my knowledge of their business. In project after project I became the lead business process architect as my approach and requirement to diagram everything helped senior leaders identify inefficiencies and opportunities. It was this experience combined with the revelation that my business partners all had IT backgrounds that I realized the end of IT was coming!

Not following? My hypothesis is that as we digitize businesses the people within IT, by necessity, become acutely aware of the ins and outs of a business process. As their job responsibilities grow they naturally become aware of the ins and outs of other business processes and the integration of how processes work together. They live the reality of the interconnectedness of business processes and their automation gaining an education on both sides simultaneously. By comparison their business colleagues gain additional depth on the business side but are largely shielded from the technology. As the pace of business continues to quicken, as it has throughout time, depth becomes less important giving way to breadth (i.e. a company needs fewer specialists but they are still needed, and more generalists). As if guided by Darwinian evolution, IT analysts are becoming the experts on the business as well as the technology used for its automation.

Companies are slowing realizing this largely untapped natural resource and have begun moving IT people out into the business vs the trend ten years ago to move business people into IT (which was necessary and a good thing). Therefore my prediction, if my hypothesis is correct, is that IT will slowly dissolve back into the businesses as the level of knowledge about technology takes a revolutionary step forward in a short period of time. The end result is an IT that is largely fungible between internal and external expertise. And cloud computing will help expedite this changeover through its concentration on automation.

IT will continue to exist, but its form will change dramatically! All the strategic planning and architecture will be done in what we now call "the business" and design, implementation, operations and program management services will be used (whether internal or outsourced) to execute on the plan. The CIO of today will become the COO of tomorrow and the CTO of today will be focused on one or more of the services and very likely will not be an employee. If I had to lay all of my cards on the table I'd argue the new role of consulting will be that CTO role and management of the services which will be executed by the traditional systems integrators.

If I'm correct, things to keep in mind include:

1. Vertical domain expertise will be required for those in IT who want to be on the forefront of the revolution
2. As a revolution I believe the critical mass will be reached rapidly and therefore believe the change will occur over the next 8-10yrs
3. Cloud computing will help drive this change
4. A natural synergy is the decoupling of internal technical expertise from its application which has hindered companies for decades from making great leaps
5. Legacy systems will not hinder the revolution because they're already in the mix due to the issues of cost, complexity and compliance
6. Demographic challenges in finding qualified people will drive the consolidation of positions that used to be split between the business and IT
7. Companies who get it right will benefit so tremendously they'll never turn back
8. The shift is already underway!