[no subject]

1) The overall architecture on an app. including hardware/software has
to be signed off by the architecture committee.  This is pretty
high-level stuff like seperation guidelines for web-servers / app
server / database, OS versions, use of the SAN/NAS, backup solutions,
HA clustering, etc.

One strange rule my client has is no Java on Windows Servers.  Instead
they mandate SLES (but with Webspere as the app server)!!!!

Two types of variances are provided.  Permanent and 18-month. 
18-month variances must be fixed or re-authorized by the end of the
time.

2) The project is next submitted to the infrastructure team to ensure
only company supported languages, libs, compilers, JREs, 3-rd party
connectors etc. are used.

Same variances allowed

3) The plan is next submitted to the IT Security team which ensures
all sorts of things, including proper testing, docs, seperation of
duties, change logs,  etc. as required by SOX.

This is basically a IT Application Security Assessment in its full
glory.  In addition to providing a lengthy narrative describing the
system, there are a couple hundred specific questions that must be
answered.  The ISO 17799 assessment guidelines may help you to develop
this portion, but the best thing might be to hire a CISSP to help you.
(Certified Information Systems Security Professional)

Same variance types allowed.

Then to add to the expense, all systems are implemented in triplicate:
   Production, 
   QA / release testing,
   Devel.

The Production and QA env. have to be as identical as possible
including the QA SAN/NAS, QA Oracle Server, QA backup server, etc.. 
The dev env. can be scaled down if desired.  (ie. If you need HA
clustering for prod., then QA must be a HA cluster too, but devel.
does not have to be.)

Actual devel. and rollout is managed by a change control board.  The
CCB's main job is to ensure changes are known throughout the company,
downtime is minimized, and that you have a plan for reversion if
things go bad.

I must say, just writing the above e-mail was a scary process.  It is
amazing how expensive all of this is, but I agree with you that SOX
mandates policies and procedures be put in place to manage systems
that are used in generating reports to the SEC, and unfortunately 
that seems to be most core systems in a large company.

HTH
Greg
-- 
Greg Freemyer


</pre>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<hr>
<ul><li><strong>Follow-Ups</strong>:
<ul>
<li><strong><a name="00303" href="msg00303.html">[ale] OT: Development practices</a></strong>
<ul><li><em>From:</em> jb at sourceillustrated.com (John Wells)</li></ul></li>
</ul></li></ul>
<!--X-Follow-Ups-End-->
<!--X-References-->
<ul><li><strong>References</strong>:
<ul>
<li><strong><a name="00269" href="msg00269.html">[ale] OT: Development practices</a></strong>
<ul><li><em>From:</em> jb at sourceillustrated.com (John Wells)</li></ul></li>
</ul></li></ul>
<!--X-References-End-->
<!--X-BotPNI-->
<ul>
<li>Prev by Date:
<strong><a href="msg00296.html">[ale] NAT Help needed!</a></strong>
</li>
<li>Next by Date:
<strong><a href="msg00298.html">[ale] NAT Help needed!</a></strong>
</li>
<li>Previous by thread:
<strong><a href="msg00282.html">[ale] OT: Development practices</a></strong>
</li>
<li>Next by thread:
<strong><a href="msg00303.html">[ale] OT: Development practices</a></strong>
</li>
<li>Index(es):
<ul>
<li><a href="maillist.html#00297"><strong>Date</strong></a></li>
<li><a href="threads.html#00297"><strong>Thread</strong></a></li>
</ul>
</li>
</ul>

<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
</body>
</html>