Curated for content, computing, and digital experience professionals

Tag: compliance (Page 2 of 2)

Reminder! Compliance and the “Fear Factor” Webinar

$25 billion.
That’s the cost of compliance in the U.S. Securities Industry for 2005 according to the Securities Industry Association (SIA).

59 percent.
That’s the percentage of respondents to a SearchStorage.com poll that did not know if they were in compliance because they could not figure out what they have to do.

$15 million.
That’s the amount Morgan Stanley was fined for failing to produce tens of thousands of e-mails during SEC investigations from December, 2000 through through July, 2005.

No wonder compliance issues today = fear. They don’t have to.

Compliance is about recordkeeping. The core issue is surprisingly clear — focus on the lifecycle of paper and electronic communications – how information is created, routed, managed, accessed and archived.

Join us tomorrow, November 9, 2006 at 11:00am EDT for my panel discussion with Omtool CTO Thaddeus Bouchard and HP Financial Services Solutions Manager Joseph Wagle to discuss how to make compliance practices a seamless part of your business processes. Register here.

RedMonk’s Look at Compliance Oriented Architecture

I will start with an analogy.

A long time ago, before XML had been invented and when SGML was a new, radical idea, I often found myself having to explain how SGML was different from the kinds of typesetting codes and other markup that were already familiar to people in publishing. The reason that I was in this spot was that my business partners and I had created a product that produced SGML markup. But nobody, as yet, knew why they would want SGML, much less our product.

The analogy that seemed to work best had to do with cakes and recipes for cakes.  If I give you a cake, all you can do is eat it.  But if I also give you the recipe for the cake, well, then you can bake one for yourself, or
make a bigger one, or a sweeter one, and so on.  SGML was like having the recipe.

Well, it is a wonder that anyone knew what I was talking about. Maybe the pitch worked  because people liked cakes. I suspect that some of them got stuck on the image of eating a cake and then came away with warm feelings about our product. Anyway, what I was trying to get after was the value of abstracting rules. You can deal with the thing (the cake), but you have a lot more power and  flexibility if you deal with the rules for making the thing.  Control of product is great, but control of process is even better.

Which leads, of course, to compliance.

James McGovern sent me a trackback ping from one of his blog entries in which he references a paper by Stephen O’Grady of RedMonk titled “SOA Meets Compliance: Compliance Oriented Architecture.”  The paper came out last summer, but was new to me, and may be new to you.  It is a good read.

You should read the whole paper (it is free), but here is the argument in a nutshell:

  • Many companies are taking a “project” approach to compliance requirements.  So, SOX compliance becomes another Y2K problem. And HIPAA (Health Insurance Portability and Accountability Act) compliance becomes an entirely different project–yet another Y2K.  At least with the real Y2K, there was only one of them …
  • This is bad news, since, unlike Y2K, SOX or HIPAA are never “over.”
  • This is also bad news because each compliance “project” tends to stand alone–separate resources, costs, and headaches.
  • But, in fact, many of the same kinds of information and views of that information are required for the different compliance efforts.

So, the RedMonk paper proposes a “Compliance Oriented Architecture” or “COA,” — a specific instance of a services oriented architecture — so that companies can address different compliance requirements with a single investment in compliance services.

The proposal is another instance of the importance of focusing on the recipe, not the cake.  Rather than rushing off to the store to get all the ingredients for one cake, and then heading out a second time to buy more ingredients for a second cake, you realize instead that there are common ingredients.  With a little planning, you can maybe even bake both cakes at the same time.  (I’m hungry already …)

O’Grady describes the COA as emerging from a “radical–even heretical–notion.”  The heresy is the assumption that there are services that are common to the different regulations with which companies must comply.  The heart of the paper is a table in which O’Grady sketches out a starting list of such core services along with vendors and products that offer these services.

He may be a heretic, but I am sure that O’Grady is right about his core assumption.  Using the old arguments for SGML as an analogy again, the key here is to enable “reuse.”  Companies must move toward
architectures that can support many compliance applications with from a single system.  As with SGML, the key to value is in looking at the process, not the product.

So, it is a good paper.  But I have a misgiving about the focus on “compliance” in “Compliance Oriented Architecture.”  I can see where O’Grady is going … wanting to get companies to stop thinking of SOX, HIPAA, and other compliance requirements as separate projects — seeing them instead as instances of one, bigger thing.  But I wonder whether we shouldn’t perhaps go for something even larger … “Governance?” “Internal Control?”   My discomfort is with “compliance” as a primary objective.

Another analogy:  When driving a night, I “comply” with the 45 mile an hour speed limit on the five miles of narrow road leading  down the peninsula to my house because I want to have the car under control when a moose steps out in front of me.  (So far, I have been able to stop.) Compliance is a good idea, but it is a side effect.  The primary goal is to be able to stop the car in time.

It seems that some of the same thinking applies here, and so I am not sure about “Compliance Oriented.”  But that is a small detail that does not subtract from the real value of O’Grady’s paper.

Stellent Releases Version 7.5 of Its Sarbanes-Oxley Solution

Stellent, Inc. announced the release of version 7.5 of the Stellent Sarbanes-Oxley Solution, a product designed to help companies streamline their processes for complying with the Sarbanes-Oxley Act. The new features and functionality in version 7.5 are enhancements developed to speed implementations, increase ease-of-use and augment reporting capabilities. The enhancements also were shaped in conjunction with input from Protiviti Inc., an internal audit and business and technology risk consulting firm, with whom Stellent holds a strategic integration and consulting agreement. Stellent provides content management-based solutions to help companies streamline processes related to complying with a variety of regulations, such as the Patriot Act, Health Insurance Portability and Accountability Act (HIPAA), ISO, and the Sarbanes-Oxley Act. Stellent’s compliance solutions allow companies to manage and approve content related to financial and non-financial disclosures, as well as documentation associated with an organization’s enterprise risk management process. The solutions are based on Stellent Universal Content Management system, which offers document management, Web content management, digital asset management and imaging, supported by collaboration, records management and business process management services. Stellent Sarbanes-Oxley Solution 7.5 is available today. www.stellent.com

Newer posts »

© 2021 The Gilbane Advisor

Theme by Anders NorenUp ↑