Ok, of course this was bound to end in a flame war - once again, the whole "developer vs CNC" argument has arisen on the board. Luckily this isn't actually the situation in a day-to-day work environment - but there ARE times when developers AND CNC guys overstep their marks...
Now, first of all, I'm exhausted today - I had to rescue an implementation over the weekend, and I just flew back to my regular customer - and I literally had no sleep last night - so if my comments seem "curt" or a little out of character, I apologize in advance !
Secondly, I thought we already had a big argument not that long ago in another thread with almost exactly the same question being asked ?! I'm not sure that anyones opinions are different from then....but nevertheless...
So, let me answer Greggs comments...
[ QUOTE ]
[ QUOTE ]
Because, to "appease" the functional folks, developers will take short cuts that end up crucifying the system in the long term.
[/ QUOTE ]
Wow, that's a cynical point of view. Do you really want to classify all developers as kiss-ups to the functional guys? That's not all accurate.
[/ QUOTE ]
No, you're right. Not all developers are like this. I was actually aiming this at the development ORGANIZATIONS that I have seen set up in the past. Maybe they don't specifically "kiss up" but the organization will certainly agree to any specification or change in the system proposed by higher-ups or the business.
This is actually a criticism of many development organizations - where the development team is a "service" that is used by the business - ie, their customer. When this occurs, "the business is always right" - and the development organization pretty much develops based on whatever their customer requirements are - then there is always going to be friction against a "standard/vanilla" JDE style environment. Not saying that ANY JDE environment is "standard" or "vanilla" - but there are definite long-term advantages to ensuring that the code is as "vanilla" as possible.
Now, whether having a separate CNC or Development Manager being able to curtail the changes, is another matter. If the CFO demands that a change needs to occur, then usually that change occurs. Decisions are not always made with the best advice !
[ QUOTE ]
[ QUOTE ]
CNC folks are naturally distrustful of change, have a much better understanding of the architecture, and therefore are much better suited to being the "goalkeepers" of what gets promoted to production.
[/ QUOTE ]
Jon, The CNCs aren't the goal keepers of the code. We're the goalkeepers of the system and security, but not the code. The goalkeeper of the code is the development manager.
[/ QUOTE ]
True in your case, but in many other cases, the role of Development Manager is a task shared by the CNC - or the development manager is viewed as a "part" of the CNC group. However, either way you look at this, the GOALKEEPER'S role is to keep out bad code - and not allow the DEVELOPER (code writer) to promote unless the code has been tested thoroughly and meets correct standards.
[ QUOTE ]
[ QUOTE ]
Not only that, but if you work in any public organization in the US, developers are STRICTLY not allowed to promote ANYTHING to production - its called SOX Compliancy, and its probably the only SOX compliancy regulation I completely agree upon.
[/ QUOTE ]
That's a load of crap - SOX is about segration of duties, it doesn't get anywhere near that specific. SOX is all about interpretation by the auditing firm and developing good strong best practices that work for the company and the auditors. SOX is about setting a policy and following it. We have undergone twice annual SOX audits for years, the auditors have no problems with our developers managing the object promotions. The key is that all objects and projects are documented in a strong change control process. Before an object is modified or created, there is a written business case for it. From DV through to PD there are documented change control documents with appropriate managers and/or functional experts signing off on the changes.
[/ QUOTE ]
OK - this is the "crux" of this post, and why I felt I had to put some more explanation to my original quote.
First of all, Segregation of Duties has NOTHING to do with Sarbanes Oxley. SOD is often implemented as part of a SOX initiative - but SOX does NOT require SoD in any way, shape or form.
You are also incorrect about SOX not being specific. A quick read of the wikipedia summary of the SOX act (
http://en.wikipedia.org/wiki/Sarbanes-Oxley_Act) identifies that although there are certain controls that are "loosely" defined, there are very SPECIFIC controls that are MANDATED by the SEC - by law.
Section 302 mandates that internal controls have been documented - which is what you are referring to - but section 404 mandates the ASSESSMENT of internal control - and this is where the entire thing gets a little tricky. A large number of auditors are now using COSO (
http://en.wikipedia.org/wiki/Committee_of_Sponsoring_Organizations_of_the_Treadway_Commission) as an answer to section 404 - and this is starting to integrate SoD into SOX.
Now, the question is whether these auditors SHOULD be using COSO - which, at the end of the day, is not a SOX requirement, but if implemented, does answer section 404 of SOX. The point here is that auditors like to implement "known" systems (and also like to implement controls that they can benefit from with vast billable hours !). The quote from the Wikipedia website states
[ QUOTE ]
Under Section 404 of the Sarbanes-Oxley Act, management and the external auditors are required to report on the adequacy of the company’s internal control over financial reporting. Auditing Standard No. 5, published by the Public Company Accounting Oversight Board, requires auditors to “use the same suitable, recognized control framework to perform his or her audit of internal control over financial reporting as management uses for its annual evaluation of the effectiveness of the company's internal control over financial reporting”
[/ QUOTE ]
So this means that as more and more companies allow COSO to be implemented in their IT Controls, then more and more auditors will require SoD as part of SOX Compliancy - and, therefore, is far more specific and restrictive than the original ideas behind SOX.
I've been quoted on SOX compliancy a number of times before, as far as development and IT Controls (I provided a presentation on SOX compliancy for Collaborate last year) but even I can see the chalk on the wall as far as how code is promoted into production.
The question is, of course, is whether SOX will continue. There is a lawsuit which just the other week went to the supreme court about whether SOX and the Public Company Accounting Oversight Board is constitutional. The complaint argues that because the PCAOB has regulatory powers over the accounting industry, its officers should be appointed by the President, rather than the SEC. Further, because the law lacks a "severability clause," if part of the law is judged unconstitutional, so is the remainder.
On May 18, 2009, The United States Supreme Court agreed to hear this case.
Long winded, I know, but I'm still in favor of separating the developer from promoting code into production - and instead ensuring that a development manager or CNC be the oversight to promotion. If that process is "too long winded" then it needs to be sped up - but I've seen too many issues with code promotions and spec corruption, and after all, wouldn't the developer prefer just to code instead of having to trace why code didn't promote correctly ?
Flame on...
) unless I have to; and I would probably NEVER start off taking an ESU from Oracle and putting it into PROD FIRST as a CNC or even a Service Pack without testing in normal DV - PY - PD cycle. So I'm not sure about that Oracle recommendation and I don't agree with it after 14 years of field experience.
