Re: Separation of Duties...

Mark V. --->We have survived quite well among the many.

So did the dinosaurs for a while, the days of the IBM midrange being a
GREAT machine for small/medium businesses who could thrive with a 1 or
2 man shop and a machine that jsut flat out ran forever are
gone...............

It's now the "big boys" using the LPAR's, managing server farms hosted
on the System i, etc. the small/medium world is now
Windows.................

On 12/29/07, Mark Villa <iseries.4.me@xxxxxxxxx> wrote:

Hi Kenneth & all,
How did this work out, defining roles?

can anyone share a compelling argument for not separating these duties?

a) size of this division and mission statement clearly do not support
the architecture prescribed by the audit requirement and therefor,
does not apply.

b) No active development is occurring and effected area of audit is
being phased out.
I am guessing that you or at least one reader here is in a
publicly traded Inc. In the larger orgs, there are people to do the
roles. This makes it painless and appropriate. I also think it makes
it effortless to define. Let me give you an example. The assumption is
you can copy from a common source (google) or ask your Oracle - MS/SQL
- AIX/MVS DB2 DBA to define her role. Her response should be, no
problem, I will send you the job scope and task docs I have. Scan it
and change all occurrences of the DB to DB2/400 DB2/i5 (or whatever
the name is now) and your done....almost.
Next, is where your knowledge comes in to play to go through and
put assignments for the i5 into the doc (example only):

A) Task is N/A - (Ref ibm....blah blah)
B) Task is OS/400 embedded and System Administrator role. (Ref: IBM....)
C) DBA or DBA Assist. performs this role.

Now that iSeries DBA duties are written and assigned you have a
documented procedure, my understanding is that this is 90% of the
battle - all actions can be traced to the owner for any I/T DB asset.
If discrete controls/security are a sticky point in these audits
(I have not participated in one since 2000), my recommendation would
be to get another i5 for the DBA and separate data from code. This
idea won't make it far. Two i5's provide a logical barrier that the
other databases have, a self contained asset. The physical barrier has
no meaning except to the guy paying the bills. You can always build an
i5 farm like the WIN farms we see. Now that partitions are becoming
mainstream on i5...that is the newest choice for all of us not using
the big-iron, where the DB has always been in it's own partition and
the jobs have another partition.
The sticky part might be the people assigned. There is no reason
why the MS/SQL DBA can not be the assigned person. I have worked on
projects where this tends to be favorable for the teams. More
organization knowledge is spread around the teams. The DBA's are
usually very surprised at how easy it is to manage the AS400 DB. The
i5 guys are interested in all of the requirements the DBA's bring to
the table. Now that everything is more global/important/open (and we
want a smooth audit). The i5 team generally likes to implement the DBA
rules and might not have done so without the DBA from a more painful
platform.
The i5 DBA may only need to provide oversight and sign-off. Does
she REALLY need to be the person hitting the key? I doubt it.
This is all a prerequisite for who becomes the owner for
promotions. After development, a different human needs to review these
roles to promote all objects to QA from these roles. Since all roles
are defined, no parts of the application are omitted. A third human is
used for production. In theory, the Dev team has no idea about things
happening in production except from human #3 problem/incident reports.
This all adds overhead and AS400 programmers (I think) do not
like being slowed down by red tape, we are (were) accustomed to having
a free hand on the iSeries. Spoiled a bit I think. Since the DB was
integrated and could never become an orphaned un-managed business
asset / could not be mismanaged as an entity in itself, it was an
easy way to save time & money by combining roles from the mainframe
playbook, the source of all of this.
Roll the clock forward decade by decade. Now our little shop is a
coast to coast chain and what started as a PROD DATA LIB is now 1 of
20 databases we work with. It is easier to see that the DBA role makes
sense now. It needs to be accounted for using "DB standards" to a
third party reader.
I have had the pleasure of working with quite a few shops so I am
pretty open minded about roles, DB, etc. It usually end up being a
win-win any way you slice it, and is our goal. Most iSeries folks I
have ACTUALLY worked with tend to be data processing gurus and I/T
generalists not specializing in any one particular dark art, i.e. DB.
You do not have to go far to hear the story about the lone programmer
that created entire "WIP or OE system without any drawings or fancy DB
techniques". in 10 days maybe.... Why are those days "long gone"
anyway?
I think most of us underestimated, in the beginning, how a role
of I/T "generalist" using the "all purpose business server" would
prepare us for the endless mix of technologies we are swimming in. We
have survived quite well among the many. Just my two cents.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.