Just a lead in: cloud computing will be vital for "small" businesses because "a man's got to know his limitations."
Now we might twitter, and for all that companies growing from startup to second stage, usually around 5+ employees, all at once notice a rumble in the fuselage.
We had service bureaus, used ADP for payroll, and edge into Quicken to run the books. Cloud computing, next big thing (and has been for years).
Monday, October 13, 2008
Tuesday, August 12, 2008
Disaster. Recovery. Invention.
In most of this last year's pieces here at the land of SANNAS (a fine team of wonks and also a fantastic snack with a good lager) the theme often centered upon increasing demands of distributed ephemeral data and the challenge of managing the process of custody and validation.
This article's being typed into a 1Gb stick; about 2Mb of that stick contains an encryption program; acceptable overhead IMHO for the promise of securing the Next Great Novel and Sudoku downloads, as well as the launch codes for the Acme ® ‘Lil Armageddon family of products, my sonnets to Paris Hilton and other juicy bits.
I do not, as they say, keep a tidy desk. My brain stays healthy by understanding my own LIFO filing system and an ability to understand the strata and the high probability parts of the piles wherein nestles the Airline Magazine or the clipping of a local paper's crank I wanted to riff upon at leisure. This represents an elegant strategy promoting mental health albeit with a risk of structural collapse of the entropy-friendly piles of the arcane lore.
Somewhere, someone must be working on a desktop computing metaphor that allows for significant standing loads. Bearing walls. Like that. At the very least, maybe something like "The Clapper" to find that 1Gb slice of memory...
So, here's the thing: data all over the place, connected and unconnected with the not so subtle growth of metadata to describe the context and provenance of information along with the burden of incremental data to manage the data and thereby the added processing cycles for data management itself. Extremely bright designers have delivered high value tool infrastructures, and I, for one, am not worthy of holding their pocket protectors in the area of difficult code and algorithm implementation, and generally customer focused implementations.
But in the realm of Disaster Recovery mechanisms and services, preemptive trumps reactive. Some scenarios of the mode of disaster, use cases, deliver an example.
Pandemic Flu, Weather, Earthquake, Toxic Spill, extended outages of power, water, other broken infrastructure should be the object of sandtable exercises, at a minimum, to game through what (might likely) work in these scenarios.
Rather makes removable media a bit of a problem during times of "saw fan, engaged same", not to mention getting to the unnetworked unautomated and unavailable mélange of annotated manuals and Post It notes which, don't you know, are the keys to the kingdom, whether one acknowledges that or not.
The adhocracy of portable data (iPhone, et.al.)seems to drive the industry towards some sort of nexus, wherein the overall practice and form of storage management and optimization will trend toward something that looks very much like Open Source toolkits and standards. For some this will be the defining disaster; however, other mature technology (e.g., MVS et seq) informs us that the core functionality and benefits of the "mature" technology do not by any means always disappear, but become the subject of new core businesses and invention. Ye Olde Virtual Machine has shown a tenacity in meeting the market need, albeit in quite new forms.
So, vis a vis Disaster Recovery, the pressure is on for shifts that make for highly interoperable and fungible networked storage resources (think Googleplex) with arbitrarily attached processing and storage tools. A lot of the "math" to predict the future comes from the good works of people like Gene Amdahl and Jim Gray (of Microsoft fame) in that a feasibility test can be accomplished with relative ease; with new cost factors and performance factors in hand, the maxim of "in the long run, all costs are variable" will again prove in with new invention. Of particular interest will be the results of open standards initiatives (akin to Web 3.0 posited mechanisms)where ontology will bloom like kudzu in Dixie.
And that, as the young lady informs us, is "hot".
This article's being typed into a 1Gb stick; about 2Mb of that stick contains an encryption program; acceptable overhead IMHO for the promise of securing the Next Great Novel and Sudoku downloads, as well as the launch codes for the Acme ® ‘Lil Armageddon family of products, my sonnets to Paris Hilton and other juicy bits.
I do not, as they say, keep a tidy desk. My brain stays healthy by understanding my own LIFO filing system and an ability to understand the strata and the high probability parts of the piles wherein nestles the Airline Magazine or the clipping of a local paper's crank I wanted to riff upon at leisure. This represents an elegant strategy promoting mental health albeit with a risk of structural collapse of the entropy-friendly piles of the arcane lore.
Somewhere, someone must be working on a desktop computing metaphor that allows for significant standing loads. Bearing walls. Like that. At the very least, maybe something like "The Clapper" to find that 1Gb slice of memory...
So, here's the thing: data all over the place, connected and unconnected with the not so subtle growth of metadata to describe the context and provenance of information along with the burden of incremental data to manage the data and thereby the added processing cycles for data management itself. Extremely bright designers have delivered high value tool infrastructures, and I, for one, am not worthy of holding their pocket protectors in the area of difficult code and algorithm implementation, and generally customer focused implementations.
But in the realm of Disaster Recovery mechanisms and services, preemptive trumps reactive. Some scenarios of the mode of disaster, use cases, deliver an example.
Pandemic Flu, Weather, Earthquake, Toxic Spill, extended outages of power, water, other broken infrastructure should be the object of sandtable exercises, at a minimum, to game through what (might likely) work in these scenarios.
Rather makes removable media a bit of a problem during times of "saw fan, engaged same", not to mention getting to the unnetworked unautomated and unavailable mélange of annotated manuals and Post It notes which, don't you know, are the keys to the kingdom, whether one acknowledges that or not.
The adhocracy of portable data (iPhone, et.al.)seems to drive the industry towards some sort of nexus, wherein the overall practice and form of storage management and optimization will trend toward something that looks very much like Open Source toolkits and standards. For some this will be the defining disaster; however, other mature technology (e.g., MVS et seq) informs us that the core functionality and benefits of the "mature" technology do not by any means always disappear, but become the subject of new core businesses and invention. Ye Olde Virtual Machine has shown a tenacity in meeting the market need, albeit in quite new forms.
So, vis a vis Disaster Recovery, the pressure is on for shifts that make for highly interoperable and fungible networked storage resources (think Googleplex) with arbitrarily attached processing and storage tools. A lot of the "math" to predict the future comes from the good works of people like Gene Amdahl and Jim Gray (of Microsoft fame) in that a feasibility test can be accomplished with relative ease; with new cost factors and performance factors in hand, the maxim of "in the long run, all costs are variable" will again prove in with new invention. Of particular interest will be the results of open standards initiatives (akin to Web 3.0 posited mechanisms)where ontology will bloom like kudzu in Dixie.
And that, as the young lady informs us, is "hot".
Thursday, July 17, 2008
Disk Payload Management
Transfer of data has an upper bound of the speed of light and a lower bound of amount of a budget, excluding strange action at a distance and physics not yet known. It's all fun and games until something divides by zero.
In a delightful teaser article, Neil J. Gunther's "The Guerrilla Manual" delivers a bolus of refreshing views on capacity planning and performance management with a cleansing amount of terse common sense.
In particular, he notes, "You never remove the bottleneck, you just shuffle the deck."
Network Effects and Blinkenlights
Back in the mid 1980s, at least one large financial institution allocated IT budgets using a simple ratio of numbers of customer accounts by type, with appropriate finagle factors. At least it was a model that, assuming a lot of linearity, had simplicity and apparent transparency going for it.
Of course, these were the times of data centers with big boxes, and the occasional minicomputer. The unit costs of processing, networks, and storage were significant vis a vis cycles or bits or bytes per dollar and cycles per watt.
Of course, also, the use cases for the technology moved rather slowly, with occasional punctuation with growing online inquiry from, say, customer service agents or the addition of Automatic Teller Machines to the CICS olio of the big iron code.
More gadgets and new approaches to programming by the end users (unclean!!!) resulted in rather surprising effects upon infrastructure through rampant flaming queries (what did he say?) and even complete suites of large scale computing systems dedicated to new types of models. In the case of financial services, one big dude jammed with APL for determination of fixed income dynamics. APL, for those who don't recall, was developed for passive aggressive savants who didn't want management looking into what they'd written. But, with letting the punishment fit the crime, APL rocked for matrix operations and was a darling of the early generation of quants, including those laugh a minute actuaries.
Somewhere, someplace, someone is hacking FPGAs to stick into the Beowulf cluster of X Boxes. I gotta feeling.
So where were we... Oh, so the point is that the common factor around these early instances of "end user" computing involved moderate and increasing network effects. Transactional data could be used as feeds to these user managed systems, and network effects with emphasis upon storage and I/O tuning became significant as a means of moving the bottleneck back to the cpu. Now pick another card.
The disk to disk discussion comprises several use cases, ranging from performance optimization (e.g, put the top 10 movies on the edge of the network) to business continuance to the meta issue of secure transfer and "lockup" of the data. Problem is, how does one deal with this mess which embraces Service Oriented Architectures and Halo dynamism?
Intelligent Payloads?
This problem of placing data and copies of data in "good enough" sites on the network seems encumbered by how these data are tagged in such a way as to inform the "system" itself on the history of the atomic piece of interest as it transits other systems and networks. Perhaps something that appends usage information to the information itself, rather like appending travel stickers to an old steamer trunk tracing its owner's tours of Alice Springs, Kenosha, and Banff.
And no, I'm not advocating still another inband system monitor... more MIBs than MIPS and all of that problem.
This could, I believe, be a fertile area for new types of automation that begin to apply optimization (satisficing, most likely, in the sense of "good enough" strategies, see Herbert Simon for more G2) thereby, maybe (he qualifies again!) to reduce the amount of time and money spent upon forensics and weird extraction of information needed to govern surprisingly fluid dynamic systems.
Zipf's Law (think top 10 lists, 80/20 rule, The Long Tail issues, etc.) and other power law behaviors will still apply to the end product of such analysis, but perhaps the informed payloads will ease the analysts' management of these turbulent parcels. (Some insights to the framing of the problem of getting top level insight into systems structures and how they express emergent behaviors can be found at the Santa Fe Institute and their many papers on "Small World" problems.)
So, the bounds on this problem of course reduces to time and money. That topic also is taken up by Gunther, with emphasis upon what some of my old gang at the Wall Street joint referred to as "the giggle test" for feasibility.
This is a brief piece about an intriguing problem where more insight can be gained from Operations Research methodologies than from Information Technology praxis per se.
It nets out to (sorry) not only if it is not measured, it isn't managed, but add to that the cautionary insight of "if it isn't modeled, it isn't managed."
In a delightful teaser article, Neil J. Gunther's "The Guerrilla Manual" delivers a bolus of refreshing views on capacity planning and performance management with a cleansing amount of terse common sense.
In particular, he notes, "You never remove the bottleneck, you just shuffle the deck."
Network Effects and Blinkenlights
Back in the mid 1980s, at least one large financial institution allocated IT budgets using a simple ratio of numbers of customer accounts by type, with appropriate finagle factors. At least it was a model that, assuming a lot of linearity, had simplicity and apparent transparency going for it.
Of course, these were the times of data centers with big boxes, and the occasional minicomputer. The unit costs of processing, networks, and storage were significant vis a vis cycles or bits or bytes per dollar and cycles per watt.
Of course, also, the use cases for the technology moved rather slowly, with occasional punctuation with growing online inquiry from, say, customer service agents or the addition of Automatic Teller Machines to the CICS olio of the big iron code.
More gadgets and new approaches to programming by the end users (unclean!!!) resulted in rather surprising effects upon infrastructure through rampant flaming queries (what did he say?) and even complete suites of large scale computing systems dedicated to new types of models. In the case of financial services, one big dude jammed with APL for determination of fixed income dynamics. APL, for those who don't recall, was developed for passive aggressive savants who didn't want management looking into what they'd written. But, with letting the punishment fit the crime, APL rocked for matrix operations and was a darling of the early generation of quants, including those laugh a minute actuaries.
Somewhere, someplace, someone is hacking FPGAs to stick into the Beowulf cluster of X Boxes. I gotta feeling.
So where were we... Oh, so the point is that the common factor around these early instances of "end user" computing involved moderate and increasing network effects. Transactional data could be used as feeds to these user managed systems, and network effects with emphasis upon storage and I/O tuning became significant as a means of moving the bottleneck back to the cpu. Now pick another card.
The disk to disk discussion comprises several use cases, ranging from performance optimization (e.g, put the top 10 movies on the edge of the network) to business continuance to the meta issue of secure transfer and "lockup" of the data. Problem is, how does one deal with this mess which embraces Service Oriented Architectures and Halo dynamism?
Intelligent Payloads?
This problem of placing data and copies of data in "good enough" sites on the network seems encumbered by how these data are tagged in such a way as to inform the "system" itself on the history of the atomic piece of interest as it transits other systems and networks. Perhaps something that appends usage information to the information itself, rather like appending travel stickers to an old steamer trunk tracing its owner's tours of Alice Springs, Kenosha, and Banff.
And no, I'm not advocating still another inband system monitor... more MIBs than MIPS and all of that problem.
This could, I believe, be a fertile area for new types of automation that begin to apply optimization (satisficing, most likely, in the sense of "good enough" strategies, see Herbert Simon for more G2) thereby, maybe (he qualifies again!) to reduce the amount of time and money spent upon forensics and weird extraction of information needed to govern surprisingly fluid dynamic systems.
Zipf's Law (think top 10 lists, 80/20 rule, The Long Tail issues, etc.) and other power law behaviors will still apply to the end product of such analysis, but perhaps the informed payloads will ease the analysts' management of these turbulent parcels. (Some insights to the framing of the problem of getting top level insight into systems structures and how they express emergent behaviors can be found at the Santa Fe Institute and their many papers on "Small World" problems.)
So, the bounds on this problem of course reduces to time and money. That topic also is taken up by Gunther, with emphasis upon what some of my old gang at the Wall Street joint referred to as "the giggle test" for feasibility.
This is a brief piece about an intriguing problem where more insight can be gained from Operations Research methodologies than from Information Technology praxis per se.
It nets out to (sorry) not only if it is not measured, it isn't managed, but add to that the cautionary insight of "if it isn't modeled, it isn't managed."
Friday, June 13, 2008
Trusted Infrastructure
Every day someone (or... something) with 218 dot et dot cet dot era out of China intently checks my TCP port connectivity. Relentless, time after time, again and again it seeks what I do not know, just that it signifies.
Cut us a break? Not likely.
Good old 218 (we're on a first octet basis) and his kin know that the herd, large and lacking vaccine, eases the pursuit of new zombies and kindred grift keep those who are far, far, more than "script kiddies" hard at work.
More than to get through spam filters (v149ra, 'frinstance or his sister of ill repute, C. Alice) or help to facilitate commercial dealings involving so often the sad demise of the spouse, uncle, client, former ambassador... tragedies all. I never knew how much wealth sloshes around as the result of corpses. Ambulance chasing seems quite profitable.
"Make Money Fast" now like a Madeline evokes the time and place of a 14.4 "golden age" before a simple "delete" command would be replaced with protocols that put a Level 4 Biohazard facility to shame (and this hinkey mess o code just for a desktop!)
Nothing to see here, move along!
Richard A. Clarke, of US National Security fame, describes in his new book "Your Government Has Failed You", the results of a security exercise with Department of Defense systems. White hats commenced to do that hoo doo that they do so well... and pretty much it was "game over" in a trice: penetration aptly describes what happened.
The guvment got Intrusion monitors installed. They lit up like Bay Ridge Brooklyn on Christmas Eve with all sorts of dubious packets from UnKn0wn U53r types. Clarke quotes managers telling him that until the hoods started setting off the intrusion alarms there had never been any putative bad guys. Somehow the security tech now attracted the bums, etc. Familiar story that I'm inclined to believe.
He also advocates a partitioned Internet, hardening part of the services for secure transactions and communications.
I've been there philosophically myself; and nonetheless am avidly in favor of an unrestrained Internet as well. No hobgoblins here.
The company I was with in 2001/2002 had a trusted client server implementation that did very serious authentication (non repudiation, yadda yadda rather like Moody Blues lyrics, those shalts and shants in them there specs ballyhoo optional). Pretty much good 2 go, add Series A and shake. Well, we had the hip but not the audience.
But the big deal was that our technology needed a pretty well suborned geek to break it (it wasn't open source, and in that I now trust it less but I'm just sayin'). It kept things nice and shiny and very private as an overlay to the Big I at large. Other Big Problem though comes from oceans of distributed data.
In a world: Queue Don LaFontaine
In a world where everything moves to an emergent ad hoc architecture of networked promiscuous storage services, where devices (picture frame, 1Gb wrist bracelet, virtualized server storage complexes, distributed p2p/p4p, DRM, TiVo, and even instrumentation motes reporting on movement of RFID tags and small area hydrology and nitrogen measures, etc.etc. containing massive amounts of data) often in surprisingly readable formats.
In a world... where consumers have started to put health records within the uberplexes of Microsoft and Google (getting the providers en masse to adopt it, different problem) and the concept of insurance moves from shared risk to, well, greed seems a good word.
In a world... where the laptops of one government are targeted and tossed (usage as in noir cant) for records of another government's dissidents and the bon mots of "gentlemen do not read each others mail" have no standing...
In a world where the retiring Secretary of Health and Human Services says "For the life of me, I cannot understand why the terrorists have not attacked our food supply because it is so easy to do." (NYTimes, December 2004)
In a world where a friend takes an extended business trip, returns to find that his kids have made five movies and posted them on YouTube from his Mac.
In a world where cameras come free with the printer, and a postage stamp of silicon tells me I'm on shot one of eighteen hundred.
Trusted Infrastructure Elements
So, here's where it goes, maybe. I have two things: things one and thing two.
Ubiquitous One Time Pads: All private, all the time.
Perhaps standing the security and privacy on end makes sense. Processing cycles and (good grief I actually typed core but stet!) core become pretty inexpensive, so running an algorithm to encode everything might not be a bad way to go. Heck, with some of the new word processing file formats alleging "open" protocols we seem to be half way there already; I can't open the attachments. We already see the unit costs of solid state "drives" precipitously dropping; headroom for small processing to encrypt onchip data could be a value added feature. The great thing is that these solid state devices are so small and hold so much data. The problem is that these solid state devices are so small and hold so much data.
Distributed Spread Spectrum Storage Service
Pseudorandom multi channel information paths, with a "big enough" local store to allow for unreliable networked service. The signal (information) hides in the noise. A form of this unreliable network appears as "The Byzantine Generals" problem, specifically Byzantine fault tolerance, wherein unreliable communications mechanisms become designed "around". Reason for this part of the puzzle is that there's so much data in so many places (cheap, dense, ubiquitous) that the use case for managed services around security and recovery needs to account for mobility, and placement of user data in many places. Key point though, is that a number of public and private researchers have been going at the reliability from unreliable infrastructure for a good while now (like, even ARPANET embodied this meme) and those wacky folks at Bittorrent (for example) have large amounts of distributed secure services in their beginning gene pool plus the understanding of how to reliably place data all over whilst maintaining service levels. If the Bit folks seem too edgy, then take a look at the Akamai technology model, and throw in a dose of Meraki Networks or perhaps Spain's FON.
Point is, seems that "the industry" has a pretty solid base of knowledge in sundry places that can be applied to the secure distributed data problem, and that the notional risks to private data help to monetize the innovation's value. The architects/designers Ray and Charles Eames explored the concept of "kit of parts" for building; I think that much of that "kit of parts" exists in the public domain and will be amended with patent expiries over the next several years.
Your Mileage May Vary
That vision above, if it merits that moniker, ignores some Big Problems like distributed key management for starters, twenty volumes of USENET rants about Pretty Good Privacy (PGP), in band versus out of band control, and a whole lot of other things. I believe the joke ends with the physicist saying "we've solved the problem for a sphere." Managing distributed data "in a world" of ubiquitous storage seems the next grand challenge.
Good hunting.
Cut us a break? Not likely.
Good old 218 (we're on a first octet basis) and his kin know that the herd, large and lacking vaccine, eases the pursuit of new zombies and kindred grift keep those who are far, far, more than "script kiddies" hard at work.
More than to get through spam filters (v149ra, 'frinstance or his sister of ill repute, C. Alice) or help to facilitate commercial dealings involving so often the sad demise of the spouse, uncle, client, former ambassador... tragedies all. I never knew how much wealth sloshes around as the result of corpses. Ambulance chasing seems quite profitable.
"Make Money Fast" now like a Madeline evokes the time and place of a 14.4 "golden age" before a simple "delete" command would be replaced with protocols that put a Level 4 Biohazard facility to shame (and this hinkey mess o code just for a desktop!)
Nothing to see here, move along!
Richard A. Clarke, of US National Security fame, describes in his new book "Your Government Has Failed You", the results of a security exercise with Department of Defense systems. White hats commenced to do that hoo doo that they do so well... and pretty much it was "game over" in a trice: penetration aptly describes what happened.
The guvment got Intrusion monitors installed. They lit up like Bay Ridge Brooklyn on Christmas Eve with all sorts of dubious packets from UnKn0wn U53r types. Clarke quotes managers telling him that until the hoods started setting off the intrusion alarms there had never been any putative bad guys. Somehow the security tech now attracted the bums, etc. Familiar story that I'm inclined to believe.
He also advocates a partitioned Internet, hardening part of the services for secure transactions and communications.
I've been there philosophically myself; and nonetheless am avidly in favor of an unrestrained Internet as well. No hobgoblins here.
The company I was with in 2001/2002 had a trusted client server implementation that did very serious authentication (non repudiation, yadda yadda rather like Moody Blues lyrics, those shalts and shants in them there specs ballyhoo optional). Pretty much good 2 go, add Series A and shake. Well, we had the hip but not the audience.
But the big deal was that our technology needed a pretty well suborned geek to break it (it wasn't open source, and in that I now trust it less but I'm just sayin'). It kept things nice and shiny and very private as an overlay to the Big I at large. Other Big Problem though comes from oceans of distributed data.
In a world: Queue Don LaFontaine
In a world where everything moves to an emergent ad hoc architecture of networked promiscuous storage services, where devices (picture frame, 1Gb wrist bracelet, virtualized server storage complexes, distributed p2p/p4p, DRM, TiVo, and even instrumentation motes reporting on movement of RFID tags and small area hydrology and nitrogen measures, etc.etc. containing massive amounts of data) often in surprisingly readable formats.
In a world... where consumers have started to put health records within the uberplexes of Microsoft and Google (getting the providers en masse to adopt it, different problem) and the concept of insurance moves from shared risk to, well, greed seems a good word.
In a world... where the laptops of one government are targeted and tossed (usage as in noir cant) for records of another government's dissidents and the bon mots of "gentlemen do not read each others mail" have no standing...
In a world where the retiring Secretary of Health and Human Services says "For the life of me, I cannot understand why the terrorists have not attacked our food supply because it is so easy to do." (NYTimes, December 2004)
In a world where a friend takes an extended business trip, returns to find that his kids have made five movies and posted them on YouTube from his Mac.
In a world where cameras come free with the printer, and a postage stamp of silicon tells me I'm on shot one of eighteen hundred.
Trusted Infrastructure Elements
So, here's where it goes, maybe. I have two things: things one and thing two.
Ubiquitous One Time Pads: All private, all the time.
Perhaps standing the security and privacy on end makes sense. Processing cycles and (good grief I actually typed core but stet!) core become pretty inexpensive, so running an algorithm to encode everything might not be a bad way to go. Heck, with some of the new word processing file formats alleging "open" protocols we seem to be half way there already; I can't open the attachments. We already see the unit costs of solid state "drives" precipitously dropping; headroom for small processing to encrypt onchip data could be a value added feature. The great thing is that these solid state devices are so small and hold so much data. The problem is that these solid state devices are so small and hold so much data.
Distributed Spread Spectrum Storage Service
Pseudorandom multi channel information paths, with a "big enough" local store to allow for unreliable networked service. The signal (information) hides in the noise. A form of this unreliable network appears as "The Byzantine Generals" problem, specifically Byzantine fault tolerance, wherein unreliable communications mechanisms become designed "around". Reason for this part of the puzzle is that there's so much data in so many places (cheap, dense, ubiquitous) that the use case for managed services around security and recovery needs to account for mobility, and placement of user data in many places. Key point though, is that a number of public and private researchers have been going at the reliability from unreliable infrastructure for a good while now (like, even ARPANET embodied this meme) and those wacky folks at Bittorrent (for example) have large amounts of distributed secure services in their beginning gene pool plus the understanding of how to reliably place data all over whilst maintaining service levels. If the Bit folks seem too edgy, then take a look at the Akamai technology model, and throw in a dose of Meraki Networks or perhaps Spain's FON.
Point is, seems that "the industry" has a pretty solid base of knowledge in sundry places that can be applied to the secure distributed data problem, and that the notional risks to private data help to monetize the innovation's value. The architects/designers Ray and Charles Eames explored the concept of "kit of parts" for building; I think that much of that "kit of parts" exists in the public domain and will be amended with patent expiries over the next several years.
Your Mileage May Vary
That vision above, if it merits that moniker, ignores some Big Problems like distributed key management for starters, twenty volumes of USENET rants about Pretty Good Privacy (PGP), in band versus out of band control, and a whole lot of other things. I believe the joke ends with the physicist saying "we've solved the problem for a sphere." Managing distributed data "in a world" of ubiquitous storage seems the next grand challenge.
Good hunting.
Wednesday, May 14, 2008
Compliance CENTREX
What went around comes around.
Compliance, to pass an examination or be prepared for a contingency, has foundation from commercial good practice and regulatory (including legal) conformance.
Higher level compliance concerns evoke the wisdom of first do no harm, eat green leafy vegetables, and get moderate exercise. Business continuance, or continuance of the entity or ones job, ripens with common sense. The broader topics include fiduciary stewardship, management of proprietary internal information, and of client, patient, supplier, et.al. privacy, and, fundamentally, the determination of trust.
In forming the deeply connected systems involving the customers, the organizations, and the suppliers the challenge of determining trust provably is, well, not easy.
In a recent national survey, respondents uniformly agreed that this validation of a system, the compliance issues in managing the archiving and retrieval (or demise) of data worked, by degree, well in larger organizations but was woefully lacking in many others.
Be advised that this national survey involved three people I know.
But they were pretty far away from each other.
A couple of common themes though, on the broad area of what's up with that compliance thing?
Small Organizations Getting Crushed
Many smaller organizations encounter compliance, in the broad sense, only after something has gone quite wrong. The data systems come under the management of one "s/he who knows" and typically that s/he who knows avers that all's under control, nothing to see, move along. Quite often, that's a correct assessment but the Black Swan of Something Wicked will assuredly appear like the first tulip of spring.
The many conceivable test cases and demonstrations available to exercise a procedure or software implementation become quickly incomplete; the "many eyeballs" of the Linux community or MSDN or the SAP experts or Cisco herders or System Z mavens or Wii Wunderkind and the rest may already have the fix in hand, but the bolus of healing code remains unknown to the many.
So staying current with what's on with the system in the technology sense underpins meaningful compliance.
The management of even a small system, when networked, overwhelms or at least distracts from the business at hand, the getting the work done part of work. Script kiddies, malware, and zombie makers test test test the borders and their numbers still grow. Firewalls capture the IP of pinging drones with the tireless cold focus of The Terminator.
But enough of the light side.
Somewhere there's a law waiting to bite you.
In addition to the issues of compliance with securing systems from perpetrators and miscreants, somewhere one can find comfort in some legislation from someone who should, but does not, know "better" that will increase costs for compliance if not explicitly be purely intractable by the placement of the liability of non compliance with an impossible dream.
Those public policy decisions might include draconian warnings for browsing a Goya Maja or a 1970s Sears Catalog, and more seriously issues of record retention and access for, among other things, financial and health transactional data, and emails (which increasingly go beyond text and have average object sizes growing like Kudzu). I wonder if Wall Street still drives those tapes around in the vans, and whether aging tape drives live on to read archaic media. This leads to still more policy decisions, internal to an organization and implementations driven by external policy makers.
For the smaller organization, staying on top of the goat rodeo that entails version management of desktop OS and warring tribes of antiwhatever software chewing through silicon to the joy of chipkateers and the anguish of people just trying to get along with recreational and the oh so serious land of business computing, now that goat rodeo builds character in and of itself.
To overlay "unfunded mandates" on the already maxtasked elves of IT, well that's just Bondo on the cake.
Hence: Compliance Centrex
In the dark ages of the 1970s and 1980s, telephone companies in more urban climes implemented a product called Centrex (Centralized Exchange) service.
The mainframe (Central Office) provided features from a bunker managed by truly serious professionals empowered to code the forwarding of phone calls from one line to another, implement restrictions on calling privileges to certain telephone lines (local only, for example) and wield other powers on the users, who enjoyed very reliable consistent service. Each line got its own phone bill. Later generations of the Centrex miracle provided limited administration by the customer.
Point: a small team of skilled people can provide a lot of oomph across a customer base. 37signals with their millions of subscribers being one example already covered here.
Somewhere I hope there's a graduate student looking at the marginal utility of willingness to pay with notional conjoint analysis studies.
More fun than Facebook!
Now, the code to be cracked appeals most to small and medium scale enterprises; bundling policy based compliance features as a software overlay or a true "tin can with widgets + code inside" offers some hope. Think of an XML (etc.) publishing service informing the installed base of gadgetry on the latest rules for archiving, say, emails. Recognize also that the "big" end of the market also may actively seek compliance services: Collaborative Software Initiative's reference implementation for custodial information is but one example.
Towards the Compliance Appliance?
Here in the US, a couple of firms now warrant identity protection with a $1,000,000 guarantee($400 Loonies thereabouts). Will we see participation of new risk instruments, insurance akin to errors and omissions, appearing as part of new "tough" compliance appliances?
Compliance as a service has, I believe, legs in the same sense that an antivirus automatic update does. Some "professional compliance" process exists for food companies: third parties provide certification of the supply chain end of the food pipe to ensure that custodial information, security and hygiene of premises, etc. conform to regulatory standards. Beyond "audit" the service economy for compliance is likely quite amenable to a service provided for fee relationship, increasing service revenues for the storage company (or the applications company) along with driving new purpose into the consigliore side of the bidnez.
Continuous monitoring already available for "tested hacker safe" affirms the underlying business model.
The management of the infrastructure, especially for the smaller companies, takes too many cycles and depends upon people who rarely encounter a Black Swan in their Sarbox, eh?
Teams matter; effective new ones will cross borders of all sorts.
Compliance, to pass an examination or be prepared for a contingency, has foundation from commercial good practice and regulatory (including legal) conformance.
Higher level compliance concerns evoke the wisdom of first do no harm, eat green leafy vegetables, and get moderate exercise. Business continuance, or continuance of the entity or ones job, ripens with common sense. The broader topics include fiduciary stewardship, management of proprietary internal information, and of client, patient, supplier, et.al. privacy, and, fundamentally, the determination of trust.
In forming the deeply connected systems involving the customers, the organizations, and the suppliers the challenge of determining trust provably is, well, not easy.
In a recent national survey, respondents uniformly agreed that this validation of a system, the compliance issues in managing the archiving and retrieval (or demise) of data worked, by degree, well in larger organizations but was woefully lacking in many others.
Be advised that this national survey involved three people I know.
But they were pretty far away from each other.
A couple of common themes though, on the broad area of what's up with that compliance thing?
Small Organizations Getting Crushed
Many smaller organizations encounter compliance, in the broad sense, only after something has gone quite wrong. The data systems come under the management of one "s/he who knows" and typically that s/he who knows avers that all's under control, nothing to see, move along. Quite often, that's a correct assessment but the Black Swan of Something Wicked will assuredly appear like the first tulip of spring.
The many conceivable test cases and demonstrations available to exercise a procedure or software implementation become quickly incomplete; the "many eyeballs" of the Linux community or MSDN or the SAP experts or Cisco herders or System Z mavens or Wii Wunderkind and the rest may already have the fix in hand, but the bolus of healing code remains unknown to the many.
So staying current with what's on with the system in the technology sense underpins meaningful compliance.
The management of even a small system, when networked, overwhelms or at least distracts from the business at hand, the getting the work done part of work. Script kiddies, malware, and zombie makers test test test the borders and their numbers still grow. Firewalls capture the IP of pinging drones with the tireless cold focus of The Terminator.
But enough of the light side.
Somewhere there's a law waiting to bite you.
In addition to the issues of compliance with securing systems from perpetrators and miscreants, somewhere one can find comfort in some legislation from someone who should, but does not, know "better" that will increase costs for compliance if not explicitly be purely intractable by the placement of the liability of non compliance with an impossible dream.
Those public policy decisions might include draconian warnings for browsing a Goya Maja or a 1970s Sears Catalog, and more seriously issues of record retention and access for, among other things, financial and health transactional data, and emails (which increasingly go beyond text and have average object sizes growing like Kudzu). I wonder if Wall Street still drives those tapes around in the vans, and whether aging tape drives live on to read archaic media. This leads to still more policy decisions, internal to an organization and implementations driven by external policy makers.
For the smaller organization, staying on top of the goat rodeo that entails version management of desktop OS and warring tribes of antiwhatever software chewing through silicon to the joy of chipkateers and the anguish of people just trying to get along with recreational and the oh so serious land of business computing, now that goat rodeo builds character in and of itself.
To overlay "unfunded mandates" on the already maxtasked elves of IT, well that's just Bondo on the cake.
Hence: Compliance Centrex
In the dark ages of the 1970s and 1980s, telephone companies in more urban climes implemented a product called Centrex (Centralized Exchange) service.
The mainframe (Central Office) provided features from a bunker managed by truly serious professionals empowered to code the forwarding of phone calls from one line to another, implement restrictions on calling privileges to certain telephone lines (local only, for example) and wield other powers on the users, who enjoyed very reliable consistent service. Each line got its own phone bill. Later generations of the Centrex miracle provided limited administration by the customer.
Point: a small team of skilled people can provide a lot of oomph across a customer base. 37signals with their millions of subscribers being one example already covered here.
Somewhere I hope there's a graduate student looking at the marginal utility of willingness to pay with notional conjoint analysis studies.
More fun than Facebook!
Now, the code to be cracked appeals most to small and medium scale enterprises; bundling policy based compliance features as a software overlay or a true "tin can with widgets + code inside" offers some hope. Think of an XML (etc.) publishing service informing the installed base of gadgetry on the latest rules for archiving, say, emails. Recognize also that the "big" end of the market also may actively seek compliance services: Collaborative Software Initiative's reference implementation for custodial information is but one example.
Towards the Compliance Appliance?
Here in the US, a couple of firms now warrant identity protection with a $1,000,000 guarantee($400 Loonies thereabouts). Will we see participation of new risk instruments, insurance akin to errors and omissions, appearing as part of new "tough" compliance appliances?
Compliance as a service has, I believe, legs in the same sense that an antivirus automatic update does. Some "professional compliance" process exists for food companies: third parties provide certification of the supply chain end of the food pipe to ensure that custodial information, security and hygiene of premises, etc. conform to regulatory standards. Beyond "audit" the service economy for compliance is likely quite amenable to a service provided for fee relationship, increasing service revenues for the storage company (or the applications company) along with driving new purpose into the consigliore side of the bidnez.
Continuous monitoring already available for "tested hacker safe" affirms the underlying business model.
The management of the infrastructure, especially for the smaller companies, takes too many cycles and depends upon people who rarely encounter a Black Swan in their Sarbox, eh?
Teams matter; effective new ones will cross borders of all sorts.
Subscribe to:
Posts
(
Atom
)