Well, I know it is hard to get a word in edge wise here...but
This is a copy of an email I put on the user mailing list under the dba
project and I thought maybe folks here would find it of interest, and
maybe some on the list could tell me I am wrong on some of my assertions
even.
Jahn, Ray (R.) wrote:
<snip>
In the USA market, financial and database software products are
significantly impacted by the USA Sarbanes-Oxley Act (SOA) [ref. 1].
Due to the potential legal consequences from SOA on company
executives, all financial and database products have to prove SOA
safe, at least at the level of architecture design, in order to
prevent SOA litigation. This guideline generally applies to both
internal development and external purchased products. I am sure that
Sun Microsystems, currently headquartered in USA and a primary
coordinator of OpenOffice development, also implemented its own
strategy to prevent SOA legal liability.
This legal requirement leads to a technical challenge. In medium to
large business environments, there are incumbent database
applications managing critical business knowledge. There are robust
SQL modules, after millions of dollars and years of field testing,
connecting and communicating with various business applications to
keep revenue coming. The SQL DB communication is very likely done
through one of the popular standard connection protocols, including
JDBC.
<snip>
OpenOffice is constantly enhancing its architecture design for market
competition. Perhaps a solution is already in the works and USA SOA
safety will soon no longer be an issue or impediment for selling OO
Base products. Perhaps there is an alternative (practical) approach
that can obviate the need of conversion from sdbc.XConnection to
java.sql.Connection. I would very welcome such ideas.
<snip>
-----
1. Sarbanes-Oxley Act
http://en.wikipedia.org/wiki/Sarbanes-Oxley_Act
Wow Ray talk about touching on a breadth of issues in a single email.
How about we burst the replies ( as in bursting a batched run of
reports ).
*SOx*
Sarbanes Oxley ( I prefer the generally accepted acronym SOx by the
way, SOA is commonly used for something different, Service-oriented
Architecture ) is technology neutral for all intent and purpose. You
could say it is about process control and that would be pretty close I
guess - but I would stick with a description that ones sees often: "
SOX is all about /corporate governance/ and financial disclosure."
After all IT systems do not defraud people, people defraud people. (
Nor is it likely that anyone in the IT department, or an IT vendors
staff, is ever going to go to jail because of SOx, but their boss
might. )
Some folks reading this are likely thinking...how the heck would
OpenOffice.org ( the application ) get tied up in SOx compliance?
Answer: Section 404 of the act and End User Computing ( EUC - yes I
know another acronym with a couple of other common uses). An EUC
artifact does not have to be a system of record to be considered
worthy of auditing and control under section 404. It can become so if
any of its output is used as input to a financial system of record. (
See:
http://en.wikipedia.org/wiki/Information_technology_controls#End-user_application_.2F_Spreadsheet_controls
for an overview)
So my first question is where in OpenOffice.org ( the organization )
is this subject being discussed? To the best of my knowledge no where.
Of course you might say - well, it really is more for the likes of SUN
Microsystems, Novell and IBM to address this market segment. However
finding anything about the subject on SUN or Novell web sites that
deal with SOx, in regards to the 'the office' products appears to be
"mighty slim pick'ns". A broader search fill find some reference to
StarOffice, as in this report from the "Institute for Internal
Audtors"
http://www.insidesarbanesoxley.com/sarbanes-oxley-resources/lord-benoit/EnsuringSpreadsheetAccuracySOX.pdf
. If you actually read that report however you will find that after
mentioning StarOffice and KSpread it goes on to discuss the built
features of Excel that can be used in the audit process - no such
reference can be found for the other products.
A quick comment here about the subject of spreadsheets on a Base
mailing list - just substitute Base for Calc anywhere you like, and
what I will call the consumer / supplier relationship: A Calc file
uses a query in a Base file to generate a set of datum for a sheet -
the query is now a valid player in the audit trail. Another way that
Base is going to be relevant here, without referring to an actual Base
embedded database, are reports.
Just to wrap up this email - contrast this to MicroSoft ( the
organization ) and Office ( the application ), the subject is given
serious space on the website and a small cottage industry has sprung
up to support compliance needs for MSO artifacts. I'll leave finding
the references to these sites to the reader. [ Would be a great
subject for the BizDev group - too bad..]
Drew
--
OpenOffice.org User Community Forum: http://user.services.openoffice.org
United States PostgreSQL Association: http://www.postgresql.us/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
