My Freelance Agenda

My updated Linkedin reads like this, and I am looking for new work as a freelance internal analyst  / evangelist – creating alternative narratives that serve to rejuvenate product targeting, while elevating the discussion above the noise level .

The Enterprise IT Sector is crowded and complex. The constituent buyers of B2B Capital Line of Business software and hardware are becoming increasingly jaded and immune to standard marketing practices.

Feature / Benefit – Feature / Benefit

Whether a long and excruciatingly precipitous closing cycle, or being drowned in the advertising noise, when is the right time to create a fresh narrative? 

Selling complex and costly capital line systems to sophisticated buyers using the old feature / benefit tactic is starting to wear thin across capital line of business IT and equipment markets. There are many, many highly competitive SME companies led by Scientist / Engineer Founders who are simply being outspent on media by PE funded leviathans. 

A reworked narrative can make a difference. My campaigns are industry issue driven to dovetail with your existing marketing, to steer high-interest prospects and convert them into leads – always focusing on the essential core of what makes your org / product better, different. 

In context of the market & above the noise. Part of being in context is analyzing the competitors in your sector, while keeping watch on the developing opportunities.

My clients deliver highly crafted and refined technologies to B2B software and a few hardware markets where I have a special feel for (Test & Measurement, Mobile data, workforce management). I’m an industry relations analyst with an evangelist’s tilt – and increasingly a guide to regulatory relations

The Socialization of the Supplier Integration Sector

In my daily work as an Industry Analyst and Solutions Advocate, I am finding that the terms, “social supply chain”, and “supplier collaboration” are showing up with increasing frequency. However,  the inclusion of  opportunistic communications supplementing a supply chain infrastructure (these include EDI-based systems such as ordering automation, e-Invoicing, and generic supplier enabling); needs to be well understood and carefully implemented. I am  emphatically a proponent of fresh ideas, and  firmly in favor of  enhancing supplier autonomy.  However,  many B2B platforms, even those developed by experienced companies, fall victim to featuritis – the addition of functions without a concomitant understanding of what or who they serve.  If the industry as a whole simply must conceptualize the benefits of social media on supply chain IT, let’s at least think it through, together. Here are some elementary concepts in brief:

Today, we practice top down supplier management – something that  looks and feels inflexible to most suppliers –

cloudap

“thou shalt use this Implementation Guide”, thou shalt use X12 850 or EDIFACT ###,  with these modifications”. – – -well…that seems at odds with any vendor’s ideal model. The VANs, as a group, have offered communications and connection to ERP and order + shipping. That’s nice. Continue reading

Is it Bedtime for VANs, or is evolution possible? Check your innovation-compass, we are going on an expedition.

Upload, Download, Upload, Download, to check status of delivery go to your admin web page…..Upload, Download, call Netops support…..Ugh!!!! Horrible….bloody horrible…..

Renew VAN contract – 2 to 3 years term? What? How much? KC’s? Minimums per month? Ugh….

Request an interconnect to a TP on another VAN……How much ? Ugh……Unfair (so true).

New unexpected fees and the worst customer service experience ever. Where did these fees come from? You don’t like it? Tough. Threaten moving to a competing VAN or service provider you’ll be slapped with a monetary penalty. The unspoken, very ominous threat is that if you move, your EDI traffic will be routed into a black hole. Such punitive actions, even when threatened but not actualized, would result in criminal racketeering changes against any regulated telecommunications company. Take that to the bank.

But this is the obscure world of EDI Networks, a market dominated by a reconstituted monopoly styled after an AT&T of the 1960’s. The VAN in question did not gain market share via innovation (As Ma Bell did), but via PE that enabled the acquisition of four of the largest VANs predating the fabled consolidation….so you get the picture.

Now to reality –

When Todd Gould, President and CTO of Loren Data, created the ECGridOS Communications and Trading Partner Management API, he weighed the variables of investing the company’s resources and his time in bringing a disruptive service to a market that is infamous for moving slowly into new technologies. Todd placed a big bet that is just starting to pay off – but the potential is starting to manifest.

A) What kind of market reception should such a powerful API expect? Loren Data is handing developers the keys to ECGrid, the company’s Crown Jewel VAN; would developers care? Would they be enthusiastic? Is there enough expertise in the market to make hay with a 150 Function API, nearly a DSL (Domain Specific Meta Application Language), and create a community of developers, Applications? Or, would it just be an anomaly?  A Curiosity?  One for the books, but not a commercial success? ECGridOS is nearing 120 Million functions called – not a big number in the WEb 2.0 space, but there is not much to compare in the EDI Communications arena (No other VAN that manages its own routing table offers an API).

B) Is there enough cohesion within the present mesh of addressable TP end points (in the VAN market)? Current buzz concerns leaving VANs and buying into AS2 in-house installation. This ignores the  one and only saving grace of VANs: easy address-ability and the ease of routing a message to 400,000 trading partners around the globe. These are thinly provisioned services (as I shall expand on further), and ignoring for a moment the multifarious downsides of today’s VANs, the upsides have sustained the overall sector for almost 30 years. That’s right, the first VANs were born in the ’70’s.

However, certain VANs have stopped caring for their  clients. That’s another article entirely, but just look at the many EDI discussion boards, groups, and mailing lists documenting such weeping and gnashing of teeth. Something is very, very, wrong. There most surely are ways to deliver more value and satisfaction that will ultimately retain customers, just as providing great support factors into customer satisfaction… but that is not happening. What the entire VAN sector needs to do is a complete, top to bottom re-evaluation, and get on track to delighting customers, not merely satisfying them.

But this sad state of affairs could be turned around in a thrice. Let me tell you, that I am before all else an observer of this market. I KNOW that most mid-sized hubs and trading partners do not want to operate in-house As2 systems. They either find that out the hard way, and discover that managed As2 services are just as cumbersome as the AS2 in-house kluges. It’s a terrible way to gain a life-lesson.

It’s a hellish nightmare, what the industry is proposing as  VAN alternatives: As2, with huge license fees, creeping hardware requirements, annual $support$ for in-house crews, and the final blow, having to provide AS2 comms support for trading partners (they never asked for or required this much hand-holding with VAN mailboxes).

This myth is eating some companies alive. They say, to me, “Why oh why can’t the VANs just get their act together?”. Indeed.  Here is a little end of year story for my colleagues:

A professional without much capital, but lots of programming experience, went out to do it right: The newly formed team were experts in B2B & EDI, and they set out to get the communications setup so they could serve multiple clients. The new business would offer all of the modern data layer services, mapping, translation, and even more advanced multi-instance ESB’s that allow direct SQL attachment to their shiny new Cloud Services. They decided against offering only an “AS2 Palace” – because many of their potential customers had trading partners on VANs, and they were in no position to dictate that all of the TP’s (of every new client) use As2 and leave their VANs behind. For many good reasons, they needed both VAN interconnects and As2   – – –  oh! What to do?

They needed a holy grail. But, how does one define the “holy grail” of EDI messaging and transactional coms services?  What is the penultimate shape of a perfectly powerful, scalable, lean, agile, flexible, efficient, and cost-effective (cheaper than what is currently available) ?

All you experts on the Linked-in EDI Forums and the Yahoo EDI Mailing list…..not one existing system or a do it yourself AS2 comms package can be described by any of these adjectives:

powerful,

scalable,

lean,

agile,

flexible,

efficient,

cost-effective (Cheaper than today’s alternatives, at least)

Well, I’m waiting. Oh, please, don’t tell me you run a 3,000 user As2 system with 30,000 MDN’s a hour….that’s you…..not everyone…and you cost 100K /yearly, and took years to climb the learning curve.

We expect built-in services (as OS services, callable from any environment or scripted via  server-side languages,), for communications and messaging – email, http raw, some OS’ have fancy message queuing services in the base trunk.

For developers with ambitions beyond a typical supply chain end-user, EDI communications and associated partner-network management functions (mail-boxes, ID assignment, directories, messaging functions, reporting, tracking) call for really clever and lightweight provisioning. While the ultimate services being delivered can be indeed massive, the programmer absolutely requires these attributes:

powerful,

scalable,

lean,

agile,

flexible,

efficient,

cost-effective (Cheaper than today’s alternatives, at least)

Call a function and get your thing DONE ! – This comprises the ideal form of pure computing. Pure? That’s what IBM is betting on. Without infrastructure or very much knowledge of what has to happen behind the scenes, any service can be spun up and called from any development environment everything from SAP and Oracle implementations to WordPress and Visual Basic.

We should not even think about needing physical computing resources, but all of these lightweight provisioning services for modern-day EDI are now, yes now, able to make use of any resource with minimum costs, and , one need not posses a PhD to participate.

Recalling the story of the EDI professionals from earlier: They could not get a VAN to give them a native, reciprocal interconnect –  they were instantly considered upstart competitors by the B2B establishment. They could hardly find a VAN to sell them a mailbox…which is a poor substitute (actually a nonstarter) for a B2B Super Platform What to do?

Answer: First off, This B2B Startup business is very real, real company with real people who put skin in the game, and left their comfortable jobs to set the SME B2B SAAS world on fire.. Next, this is the story of more than one company, who are now ECGridOS developers , because they  tried everything else,  and found that was not one other EDI network messaging and subscriber management platform….none. They all discovered the value and meaning of Todd’ Gould’s (and IBM’s) enlightened concept of “call a service and handle your business”, otherwise known as “pure Computing”.  An increasing number of companies and B2B startups are doing exactly this….with ECGridOS.

Some are well-known marques in the Integration and Services sector . These companies all are turned to Loren Data Corp ECGrid, and ECGridOS….

The decision makers at these “vanguard” companies made their biggest bet on Todd Gould, the Founder of Loren Data Corp who built ECGrid, ECGridOS. and Unified As2; they concluded that Todd is, as I state,  probably the leading communications architect in the EDI sector – and that is why GXS is gunning for him.

They bet on the thought leader, and on the future of EDI services being lightweight and inspired. By signing on in the midst of the battle, they have explicitly or implicitly stated their intent to be allies – and a word is sufficient for the initiated.

Fear Not, Resellers: Every Cloud Has a Silver Lining

This is a guest post by Hunter Richards of Software Advice. The original article is located here.
VARs have traditionally made money selling and servicing on-premises systems, but now cloud computing is poised to rain on their parade. Over the next five to ten years, opportunities to resell software and hardware will dwindle as more companies adopt cloud-based systems. Processes for software procurement, implementation, and training will change, and VARs will need to change their current service offerings to be successful in this new market. Luckily, VARs have many opportunities to re-focus their business strategies.
The VAR Survival Playbook
The strategic VAR will establish partnerships with cloud vendors before competitors can. The ideal cloud partner for the VAR will have three key attributes:
  • a bright outlook such that their product will be in demand;
  • plans to develop a VAR channel in addition to selling directly; and
  • partner support in the form of software development kits (SDKs), co-marketing and training.
But the territorial victory of partnership is only the beginning of the cloud transition.  Next, VARs should make five bold moves to gain a sturdy foothold in the market.
1. Specialize. Narrow your focus to a vertical market or application category, rather than defining your company by its geographic territory. Be the first to develop vertical extensions for a major cloud-based system, and learn to speak the buyer’s language. Alternatively, gain expertise with one type of application.
2. Develop competency on a leading Platform-as-a-Service (PaaS). Learn and specialize in the developer tools for a cloud-based platform like SuiteFlex (NetSuite) or Force.com (Salesforce.com). You can build your own applications and customizations, and then market them.
3. Make the cloud’s efficiency work for you. With cloud-based systems, there’s far less need to send staff to the site. Use the extra time to start an internal, centralized sales team serving a broader territory. You can become as good at inside sales – or better than – the ISV. ISVs need sales machines.
4. Offer technology-enabled services. Because cloud-based systems are accessible anywhere, it’s easier to become a seamless extension of the customer’s organization. Develop internal competencies so customers can outsource these operations to you.
5. Promote the cloud to your existing customer base. If you can’t beat ‘em, join ‘em. We’re entering a major platform transition – there will soon be an incredible shift to cloud-based systems. Get in on the action now and embrace it. Your biggest asset is your existing customer base, so help them transition.
____________________________

Hunter Richards
Accounting Market Analyst

(512) 364-0118 (office)
(800) 918-2764 (toll free)
hunter@softwareadvice.com

 

Even the mighty shall sometimes cloudfail

Example of a Single Point of Failure
Image via Wikipedia

From the annals of Gigaom:

http://gigaom.com/2009/06/10/amazons-ec2-service-suffers-outage/

Now, If you are not a social gaming startup, but are a supply chain or POS network hosted on AWS, you can do the calculus on whether AWS uptime (excellent by any measure) is better than a solid in-house solution for mission critical infrastructure.  Maybe for some, it computes, for others maybe not.

But when the cloud fails, your alternatives have to be in place. Such as: POS systems might have a set of distributed machines to capture inbound records and route card transactions. Rapid Replenishment systems might capture transaction logs for instant replications once your cloud host comes back. You might have a set of managed APIs that broker to another cloud and then reconcile the resynch.

Many paths. However, there are some businesses that can tolerate the outages that are sure to occur as more move to remote services. One thing is for sure: The single point of failure is not just the cloud infrastructure and platform providers. The land rush to get the mid market onto PAAS solutions has been somewhat willfully blind regarding the following fact – most small /med biz has only one high speed connection, and most have not thought through the issues of hot comms failover at multiple sites.

PAAS that Gas, boys. One of the best things about hosted services in the cloud has been hardly spoken about – It’s great to have all remote offices and facilities routed to a central gateway, rather than running a mishmash of multi-point routers with arcane rules. Downside, comms. Even most SMBs in the 2-25M $$ gross revenue range have been struggling with this. It is what has made the Cisco certifications a viable IT job and created a freelance market.

Reblog this post [with Zemanta]

Cloud insanity – the Shills come out of the woodwork

oWhen people read my posts and comments on other great blogs regarding my opinions about rating and certifying cloud hosts, SAAS, PAAS, they sometimes think that I am 100% against cloud based soltuions. This is patently incorrect, as I routinely recommend hosted SAAS for project management, small business, budget constrained start ups, etc. What I do not recommend is that mid market businesses that have CLOB (capital line of business) applications, hosted on their own racks, or managed by a conventional, stable vendor, change to a cloud solution until the PAAS and SAAS providers get industry rating and certifications. The SNA shops knew this, and went through the in house/ hosted rating travail. The result? An industry in which any business owner can get insurance for business continuity disruption that is caused by IT systems failures. If you are a mid sized business with an internal server rack, distributed multisite architecture, or a hosted AS400 or new IBM architecture, you can insure your operations. You can insure any Redhat, Microsoft, BEA, Websphere, whatever installation, managed and rated SAS70, or hosted in your unairconditooned broom closet, but it will cost a little more. A nice underwriter will come to your place or your managed host’s place, and write a policy.

Can’t do this with the current cloud offerings. Doesn’t mean that cloud computing ain’t here to stay, but some folks take issue with me saying anything regarding the unrated and uninsured nature of the especially thinly capitalized PAAS solutions. Oy! But now, a shout out to a hero I have never met, Jane Mcarty,  – yeah! yeah! You go girl!

Jane actually puts her hands on web hosted apps, asks and applies proof of feature performance criteria in much the same way that any good CIO or upper level staffer would do with a licensed server application. Jane uncovers such simple and basic things that one says, “the PAAS vendor didn’t know that?, huh?”. Good on you, Jane.

It was on Jane’s stellar bog that I spotted a comment thread a few days old, where a shill for the cloud industry says, in so many words, that the time to question the cloud hosted apps is over, they are established and able to deliver, and that self styled analysts, like me, have NO BID-NESS asking what if the service goes down, whaaaaaa! Self hosted solutions go down. And then commenter Russell says one of the most amazingly naive things I have ever seen in print, maybe in my entire life”: See the actual thread here.

Commenter Russell on Jane Mcarty’s blog thread”

“Many of the PaaS providers are in business with deep pockets (Force and Quickbase), well funded by professional investors (Bungee Labs), running with established management teams (Quickbase), or conservatively managed with established customer bases (WorkXpress).”

Ok, where do I begin to refuse this insanity? How about the TechCrunch.com deadpool? No? Lets start with a quote from Tref Laplante,, a principal at Workxpress.com, who says:

WorkXpress is committed to its customers and the quality of its product.  To this end it is a privately held, revenue generating company that to date has not received venture capital funding, and therefore is not under pressure to behave in ways that run counter to its mission of customers and product.” (emphasis mine).

You can see my context on this piece of Mr. LaPlante’s unassailable logic here. But, I digress. And I wish nothing but good for workxpress.com.

On the one hand, we have Russell the unknown commenter saying that VC funded PAAS platforms are an assurance and a bulwark against the vicissitudes of having a mission critical platform beyond one’s ultimate control; Partnership disputes, forced sales by the limited partners,   and raids of the venture’s bank account by coked out CEO? Pay no attention to the man behind the curtain. Ok, got it. VC funded PAAS, though unaudited and closed to inspection, and with unknown capital reserves, is safe because is overseen by, (wait for it now) professional investors. Gawd.

On the other hand, we have a principal of a popular, (and in my opinion one of the better) PAAS shops saying that because they are NOT VC funded, they are more trustworthy, due to the fact that they are, so to speak, master baiters of their own hosted hooks and fly rods

In either case we have no idea how much runway the venture has as far as operating capital is concerned. In the case of the giants (Amazon, Intuit, Google, Gogrid, Rackspace ), when they go down, it doesn’t matter because then it is bad and you will merely get an apology and a small refund.

If your business lines are damaged, taking crucial cash flow out of your pocket, and goads the potential for civil liability (in cases of service critical business), then you are truly screwed doubly, as there are no lines of underwriting that will insure a PAAS solution for anything but the actual costs of the outage.

You people are wearing me out.

.

Reblog this post [with Zemanta]

Those Sincere yet hilarious PAAS People!

The guys over at WorkXpress.com are doing a little business continuity reassurance work today by posting a blog article about how portable their product and data architecture is, and how that addresses issues of service continuity. Well, maybe they are new to the real issues of the CLOB application world where failover means instant recovery. I am sure they are working hard on an innovative PAAS platform, but until they understand what the AS400 services crowd understood long ago – continuity means what it says, continuous or predictable Resurrection of services within a specified time frame. As to the usability issues of WorkXpress, see Jane Mcarty’s excellent blog here.

Assuring people that your cloud, PAAS, SAAS solution is just great, is no reassurance at all – it MAY work great, and MAY be reliable MOST of the time, but, if the company and the application are not rated and certified, if your business’ books are not open to any third party (so as to ascertain liquidity) such reassurances are just whitewash. See the original WorkXpress blog post here.

My reply to their post:

“That code can be exported is comforting, but in and of itself does not comprise a complete continuity solution. If a client wants to take a work group app and trade an incumbent architecture for A PAAS, one needs seamless cut-over. Seamless fail over from PASS platform to backup boxes, or to alternative cloud hosts are non-trivial. Saying that data and platform logic is exportable is less than half the battle to CLOB (capital line of business) certified reliability.

Not one or hardly any of the PAAS vendors have been rated, certified. Saying the platform code will be in escrow is also just potential whitewash that does nothing to address the issue of imminent failover. WorkExpress might be a great platform, but merely stating: “WorkXpress is committed to its customers and the quality of its product. To this end it is a privately held, revenue generating company that to date has not received venture capital funding, and is not under pressures to behave in ways that counter to its mission of customers and product…” The foregoing merely says in other words that Workxpress is unrated by a third party that audits reliability. You guys might have a great product, but for the mission critical CLOB applications, you are in the same boat as any other unrated, unaudited PAAS platform.”

If you are contemplating going the PAAS route, and handing not only your data, but your operations to an unaudited third party that proudly states that they are “privately capitalized and profitable, therefore good for you!”, be careful, very careful indeed.

Reblog this post [with Zemanta]

Specialty Product Domains

Do you have hosted (SAAS, PAAS, Cloud) tools and apps that are mired in the Web 2.0 freemium swamp? Minor modifications to features and market-specific messaging can re-target your products for a real, paying client constituencies. Yes, you can get paid for real hosted applications. Technical services, equipment maintenance, Test and Measurement, fleet services. Target, get perspective, broaden your product horizons with my services. Let me help you save that code base.

Lets say your company has a web application (or any software system) that might have the potential to cross over from the horizontal to the specialty vertical or technical industrial markets, but you are not sure how to approach the sector for validation or go-to-market? What is the potential market volume, who influences, certifies, what features need modification? Let’s go.

Let’s say you have a lead that someone, some company needs a jump start into a specialty technical market, such as product service, automotive supply chain, etc. Get me a referral and I will pay you 20% off the top of my contract. Hire me on contract to provide contract management services, and I will lop off 15% of my standard rate.

Reblog this post [with Zemanta]

The Strategist: Mitigating Cloud Computing Client Services Risk via Trusted, Blind API Brokers – Part IV

n

The Strategist: Mitigating Cloud Computing Client Services Risk via Trusted, Blind API Brokers – Part IV

The plain truth: There will be no cloud computing industry initiative where competitors will agree to ‘blind pool’, and backstop each other’s failures and outages.There may eventually be great open standards to move VMs and apps off of your cloud, but no set of commercial continuity services will ever hearken back to the days of centralized SNA shops with real plans, proven market capitalization, and legitimate durability. Rather, I would expect the next few years to look like this:

  • When a really big utility cloud (AWS / Google) goes down – you will get an apology and a paltry credit. The only consolation will be that it won’t happen often, and you will not be able to exceed their up time by running your own servers. The house usually wins.
  • When a moderately well financed cloud provider starts to fumble, there will be ample warning, because folks will be watching and pinging. Have a plan, or get continuity coverage now, or when it really becomes specifically available for cloud users.  Don’t say I didn’t warn you.
  • When a small, under-financed but buzzed up PAAS, SAAS, Cloud, whatever….fails overnight, taking your operations with it – comfort yourself by thinking how much you saved while it was working those 5 months in 2009. Really, now, Consider having at least a local or S3 proxy dup your data. Get insurance. Think before you trust business operations to a startup.
  • If I was Andy Rooney from 60 Minutes: “Have you ever noticed that all of these hosting providers have a page on how great their hosting facilities are? Even the cut rate ones say, ‘we are a level 1000 bunker with a year of diesel backup power and armed guards, and multiple super network links?” I mean, did they all copy the same page to make us feel safe?”

There is no perfect state of reliability, and that even in the days of highly centralized data shops, continuity was planned. We are transitioning from this mercantile, Web Hosting mentality, to one of running business essential applications remotely. These services are splitting into ownership  categories of incumbent giants, and start ups that have a semi permanent ‘?’ on their forehead until they achieve operational liquidity. The former apologizes and credits your account, the later disappears int the night.

The vast majority of SAAS productivity app providers use existing utility compute services, in whole or in part. It’s a cost thing – perfect continuity in the cloud, on a per-client-per-use basis would be infinitely costly. There will, however, be no comprehensive industry clearing house offsetting failures –  not in the sense of a services for profit model.

There are some shared risk examples where pooled trusts for infrastructure failures exist (to the best of my knowledge, these were at least proposed in underwriting requirements):

1) Telecom, National data haulers , Carriers-Carriers, and submarine cable system operators sometimes negotiate emergency settlement and peering agreements as a prerequisite to satisfying underwriting requirements. Sometimes these agreements predate the insurer’s audit, and are just good business. Don’t confuse these contingency plans with standard settlements – they are negotiated for extraordinary outages and lock in fees and technical requirements. Only the very large carriers can enter into these agreements with true peers.

2) Municipal and State Gov. Emergency Radio communications networks, SMR, and certain common carriers (terrestrial radio specialty comms) sometimes have emergency coverage agreements that are mandated by statute.

3 )Interstate Nat Gas and Petroleum Pipelines. Etc.

The real message here is that underneath a pool of policies is a risk pricing model that is often further underwritten by a re insurer; risk pools come together faster if there are means to offset the preponderance of risk. Flood Zones are hard to mitigate, and pools are still formed, sometimes under the stentorian bark of a state regulator. But in the case of our beloved IT clouds, we have yet to get to a place where risk to an individual business that depends on a cloud service can be priced, mitigated against, and potential technical failures limited, in their worst instances.

You may now go read up on all the happy hoooha about, “the open cloud manifesto, cloud interoperability, etc.”, good luck with all that – I’m an optimist too.

We are talking here about commercially brokered services that are paid for by a pool of insurance companies, and that are funded by premiums. We don’t get there until the primary service providers are certified, rated, and as operationally good as they can be. At that crucial juncture, where a critical mass of SAAS and Cloud hosts agree to these ratings and certs, we can price the baseline risk of outages via standard actuarial methods. Subsequently, risk offsets that are purely technical in nature can be tested and put into production. Finally, when technical services are proven to be feasible, then we can look to the reinsurance market, and viola, we have a business.

Question #1): How many service providers and Insurers have to get on board, at least provisionally, to make a real retail or B2B market that multi-line agents and specialty carriers can sell into?

Answer #1): My research was cut short before I got that far. I felt that my client knew the answer and was testing to see if I came up with a verifying figure. My best guess is that at least 35% of the top 1000 SAAS and Cloud vendors and at least three major underwriters would be required to make a realistic market for policies and payouts that make any sense whatsoever.

Question #2): Other than the actual insurance underwriting and policy sales, is there a real business model here in operating the technical services pool of a blind trust API broker/ Data mirroring / continuity services for the insurance industry? How big ?

Answer #2) Oh yes, oh my G-d yes. I am writing this series because I got far enough in my work for the last client, that I did see the foggy future in a way that mature analysts sometimes do.

How big? I believe that operating the Trusted Services Pool will be worth about 60 – 120 million annually when it hits it stride. There may be ancillary channels and opportunities along the way that could lift revenues to 250M. So, it’s not going to be a Cisco or an HP, but a specialty business funded by the small insurance premiums paid by Small and Medium Businesses that make cloud computing or SAAS a critical part of their operations. (Much of my work product was projecting these numbers).

As a matter of fact, the industry as a whole may become hamstrung if these risk offsetting services are not brought online.

Maybe someone will read this very long and not too interesting series of articles (would you rather not  be reading some romance novel?), and put me back to work researching and creating the product road map, lassoing potential insurance industry partners, and start making this a reality (all that work!).

The services offered to offset cloud computing risk is a modest challenge to provision, and is really just another cloud service with special sauces for monitoring, security, and trust. That’s it.

You were expecting nuclear fusion? The goal of these pooled services is to cap the worst losses that imply risks to the majority of small and medium business that may encounter inoperative remote services – thus  mitigating the top tier of policy payouts. The insurers pay for and pool these services with the premiums collected from the insured businesses.
Blind Trusted Services:

The Trusted Services Pool has to have all the attributes of trust to be established. Fiduciaries and controllers, technical management, and operations staff have to be checked out. The capitalization has to be audited, and its own operational contingencies have to be assured. Do you see what is happening here? The insurer’s technical services pool has to be as good or better than the hosting providers that it is backstopping.

Technical Services:

The goal is to offset the worst risk cases for data loss and continuity losses to operations. This does not mean an up time guarantee. A certain major percentage of the insured population’s data and transactions has to be preserved for a reasonable premium. To support a menu of insurance coverage levels, the following technical services will probably have to be supported over time: ( I am avoiding an exhaustive technical discussion, who has time?).

  1. Transaction Log Mirroring and ReplicationThe most basic, non data heavy service for small business is to maintain transaction logs. These logs can be shipped and ready-replayed to reestablish and reconstruct business transactions if a cloud provider goes down or out. Especially for POS and counter top retail business that are making the move from a distributed server based system, half the battle is capturing the transactions.
  2. Data Storage ProxyIn addition to table-based transactions, businesses that store document images or objects may require a backup proxy to alternative cloud storage. No big hurdle here, other than the assurance and credibility.
  3. VM machine image ready standbyIf and when (some say now) a set of elastic services cane be frozen and placed on near-line stand-by, this a service that was discussed in my research. In meetings with several VM vendors, including some heavy hitters from IBM’s superserver division, it became apparent that many instances of ready standby could be held in stasis, and re-synchronized to transaction logs in fairly short order, especially if we are catering to small and medium businesses, and not say, City Bank.I guess this is where the open cloud initiatives are going. It seems that many of the VM vendors are leading the way. For the purpose of the trusted pool, I felt after a period of study that this is possible and actually in practical use in limited cases.
  4. API call brokerage for live services uptake.There are already existing services that broker web API’s. These services provide scaling, monitoring, billing, etc. Trusted services for the insured pool would maintain a similar brokered pool of API’s that would either pass through the 1st level of calls directly to the provider, or would be cut in as an alternate route if a timeout exceeds a predetermined limit.There are a few issues here that need massaging, as it not the business of the trusted services pool to provide transaction level assurance when your cloud or SAAS provider times out for a few minutes. Rather, a trusted API brokerage really makes the preceding items more elegant to provision. Even competitors can backstop each other’s outages if the Trusted Services are blind to the parties and payments settled by the trusted pool.

The up sells beyond trusted services might cover all of the value-added items provided in the course of selling business continuity services, such as records management, facilities, and telecommunications. These would add revenue lines, and complement the agencies commission incentives.

The technical services discussion could be covered in much more depth, and I may take that on after I clear my desk. However, I wanted to close this series and show that some folks, including my former insurance industry client, are seriously looking at the business of providing indemnification services and underwriting to cloud computing clients.

Reblog this post [with Zemanta]

Rating and Certifying the Cloud Hosting and Web Application Providers. Part III

Rating and Certifying the Cloud Hosting and Web Application Providers. Part III

I have been slowly morphing my consulting practice. I usually offer myself as a product sector strategy asset. Product Managers and VP’s in the on-line applications business hire me to shoulder some of their burden when targeting specialist sectors – you know, industrial, technical, services, professional. These established clients usually have an idea of where their development efforts are heading. I came in to refine and prove the potential numbers. I developed approaches to paid subscriptions, industry specialty requirements, and I found innovative ways to exploit trade specific marketing. I was the product manager’s helper, and It was a good gig until about 2007, when the economy got soft. Analysts are the first to have their contracts cut.

Now I am delivering what I learned as an analyst, and applying this to evangelizing small and medium businesses. These folks are the end users I had quantified, targeted, and interviewed in my work for web applications providers. Small and medium bizfolks perceive the benefits of hosted services and cloud computing. They clearly perceive the benefits of fault tolerance, licensing advantages, and a simplified communications topology. These smaller accounts are certainly numerous. Can they abide having recurring computing fees forever? They certainly know that their internal server and workstation / mobile infrastructure (as traditionally delivered), costs them big time when things go bad.

The SME  / SMB, in other words, gets it. They get the benefits of Web based, cloud hosted stuff. They like getting out from under the local IT support guy, or the internal IT guy that they are held hostage to. They look forward to a time where individual routers with special configurations are replaced by safe, centralized fault tolerant networks, servers, and comm infrastructure that they can provision and pay for in a rational way. They just don’t know if they can trust you and if you will be around long enough to justify the cut over.

So, before I close this series, which might include one more post on the brokering of technical services between partners and competitors to backstop business continuity failures, I will talk briefly about ratings and certifications for any remote provider of compute and storage – out there in the cloud.

Established utility computing providers, like AWS, are probably uninsureable as far as client’s needs are concerned; they are too big, and any coverage they do have insures only their own facilities and operations, which does accrue somewhat to the client’s benefit in the very long run, but does nothing when the downtime occurs. In the case of the big dogs, your insurance is their size and need to maintain a reputation. Eventually we will get our way, and instances of client computing services will get risk based pricing, preceded by business viability ratings, and of course, certifications for good facilities, operating procedures, and back office accounting standards. I’m willing to bet the ISO is working up something in their wild and crazy working groups as we speak.

One more thing: Why is PAAS different?

Briefly: clients using unitary applications or suites have invested a certain amount of time moving from  thick client project management to a hosted solution (one example). They have probably identified ways of moving the data off the platform (I hope), and so on. They are using an application, and we have all changed applications. PAAS is like marrying your company to .Net or some other standard. There is an investment, a rather large one for the SME, actually. For the lone developer making web apps, it’s ok.

The PAAS landscape is made of some very innovative and funny systems. I think you know what I mean. Some remind me of 4GL, some will let you host a language and framework, but not the integral database, some have language environments that are made from whole cloth. As a group they are fascinating and right on the cutting edge, and they are, as a group, under capitalized and illiquid. There are exceptions, but I will bet you the best dinner in Boston that one would be hard pressed to find a PAAS provider that would allow an industry ratings organization to inspect their capital and operations profile.

If a SAAS application company is illiquid in its essence, then we find another, move the data. If a PAAS company is under capitalized, we have a larger set of problems. The way migration has been handled for PAAS failures has been shameful.

Someone once asked me if the 25M round for an on-line storage provider places them in a well capitalized position; my answer was, “it depends, but generally, no, it is not considered well capitalized for the intended target and use case – 25M in a VC round ain’t shit when rating a crucial service provider that has not attained sustained profitability and near perfect uptime.” Continue reading