Re: Separation of Duties...

["Mark Allen" <scprideandms@xxxxxxxxx>]

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.