Suggestions from Paul Drobny 2009-11-25

Colleagues;

Some thoughts I've had since the meeting:

1) While there seems to be a buzz word or TLA for just about every concept that is salable in the high tech sector, I have yet to see a reasonable term for what amounts to UC Davis' ERP. Plainly because it is so associated with vendor solutions like Peoplesoft, this TLA won't do it. Our campus and many other research 1 institutions, have what we have, which amounts to a patchwork quilt (my grandmother called them "crazy quilts") of pieces that taken as a whole make up our Enterprise Resource Planning automation. Since this is the entity we will be describing for improvement in the SSWG, I think if we had a term for it that we could use in our common lexicon, when we discuss solutions with upper management resonance will be more easily attained. Anyone have an idea for this? And, correspondingly, perhaps one of our deliverables should be a glossary of terms so anyone reading our recommendations will know what we mean.

2) I would like to delve into the buy/build/borrow decision tree which I believe should be part and parcel to the software development process. Much akin to the purchasing process due diligence, we have to make good if not excellent use of the little funding we have and that means making the tough decision not to build a solution but rather either buy one off the shelf, or integrate to one, thereby saving large sums of money, especially in labor.

3) My opinon is abstraction layers are the key to successful integration of disparate systems. Also, on the Banner project, we have learned a ton of lessons about how not to integrate (for example, by modifying the source code of an ERP vendor who continually turns out upgrades, you've put yourself in the worst of both worlds, you have nullified your advantage in purchasing off the shelf, and you have doomed your functional operations to being dictated by a third party). I'll place the abstraction layers diagram I talked about in confluence, once I can figure out how to use the wiki. I took a shot at it, but don't quite get it yet. I'm not sure exactly where to put it yet, either.

4) Data management has a role to play too. The concept of "office of record" is only meaningful if the entity models in the records are purposefully extensible to include the entire universe of attributes the model is to represent. So by definition, there has to be a method of governance to work with the "office of record" to make the entity models (objects and methods) useful to the entire user community which may well include offices and business practice downstream in the data foodchain.

Happy Thanksgiving!

• Paul

  Paul Drobny

  Manager of Systems Technology

  Division of Student Affairs

  University of California

  One Shields Avenue

  Davis California 95616

  530 752 6884

  This e-mail and any files transmitted with it are confidential and

  intended solely for the use of the individual to whom they are

  addressed. If you are not the named addressee you should not

  disseminate, distribute or copy this e-mail. If you have received

  the message in error, please advise the sender by reply e-mail, and

  "If you're listening to this song

  and you think the words are going wrong ...

  Well, they're not, I just wrote them like that."

  George Harrison from "Only a Northern Song"

----Original Message----
From: owner-sswg@ucdavis.edu owner-sswg@ucdavis.edu On Behalf Of Jeremy Phillips
Sent: Wednesday, November 25, 2009 10:00 AM
To: Software Standards Work Group
Subject: SSWG suggestions

SSWG Colleagues--

Along Hutchinson Drive, in front of Mrak Hall, there's a large metal
sculpture made of pipes and struts. On each of the struts that
supports the base of the sculpture is welded the phrase "BUM, BUM,
YOU'VE BEEN HERE BEFORE."

I discovered that sculpture early in my UC Davis affiliation, and
every time I find myself sitting at a conference table re-hashing
something that should have been said-and-done years ago, that phrase
pops into my head.

It was on a loop during our meeting this morning.

Several participants whom I spoke to after the meeting expressed
frustration and a general lack of optimism for the workgroup's
prospects.

Frankly, that sucks. Not in the sense that it's a reflection on the
participants, but rather that it speaks to some endemic, pervasive and
long-standing problems that face our campus.

That said, I think we should take a step back, a deep breath, and
another whack at this problem. Here's why I think that: there is a
confluence of factors that make now the right time to reconsider our
software development practices.

• We now have ongoing, funded, real work happening on an enterprise
  identity and access management system. While we've discussed this for
  years, we've never been so far along in the process (to the point that
  we have established vendor contracts, purchased hardware, trained
  several employees and hired others, and begun configuring software) or
  had project sponsors from outside of the IT realm (the CFOs of both
  UCD and UCDHS).

• The campus has fully committed to deploying two major apps from the
  Kuali family (KFS and RICE), has tentatively committed to Coeus, and
  I've heard whispered rumors that we're seriously looking at Kuali's
  SIS and HR apps. Again, these are not IET-owned systems (other than
  RICE).

• We're broke. The primary responses across campus are clustering and
  creating service units. IT is one of the primary targets: there is a
  widespread recognition that the existing model of 1-2 IT staff per
  academic department--which has been a significant stumbling block
  toward coordination department-level development efforts--cannot
  continue.

• Additionally, being broke means that we no longer have the choice to
  continue business as usual. More specifically, there is a recognition
  that making electronic versions of our decades-old, paper-based
  business processes doesn't really make us more efficient: we know that
  we must address our business processes before we deploy new
  applications.

Those are the main reasons I think this effort is worth our time.

At the meeting, I heard a lot of differing opinions on the specifics
of how we might proceed. But I also heard some unifying themes. I
think that those are a good starting point. So I propose that our
first task should be to make a statement of principles. My hope is
that if we start with principles, we'll have a basis for informed
recommendations on specifics.

Based on today's discussion, here's my stab at writing down some of
the principles I heard stated:

1. To maximize interoperability, sharing and re-use, applications
should be designed on service-oriented architecture (SoA) principles.

2. Various campus units currently offer or are developing a variety of
infrastructure and middleware services including repositories of
institutional data, identity management, roles management, workflow,
service publishing and discovery, etc. Development efforts should
strive to make use of these services to maximize the factors outlined
in principle 1. One deliverable from this workgroup will be a catalog
and frequently-updated timeline of available middleware services.

3. SoA does not dictate the use of any specific platform, with the
following caveats:

3.1. So long as applications are designed to SoA standards, factors
including developer expertise, software licensing and hardware costs,
code maintainability, availability of commercial and/or open source
modules and components, and community and/or commercial support should
all be considered in platform selection.

3.2. Software developed for a department, unit, or college
constituency with the intention of or significant potential to become
campus-wide services should also factor in the common platforms
supported by the Data Center and other enterprise-level service hosts.
One deliverable from this workgroup will be to outline these platform
requirements.

3.3. Even SoA services frequently offer differing levels of
interoperability to specific platforms. Development efforts that will
integrate with campus-wide infrastructure services should consider
whether the integration requirements dictate platform decisions. One
deliverable from this workgroup will be a decision matrix to assist in
making this decision.

3.4. The platform chosen for a particular application is not something
that is chosen first, necessarily, but what falls out after most of
the decisions are made. That being said, as enterprise data sources
(financial, student, etc.) and middleware services (identity and role
management, authentication, etc.) become defined in terms of APIs, the
choice of platforms will likely narrow to what is generally most
effective in tapping those sources and what other major applications
are already using.

Those are the unifying elements I heard voiced at our first meeting.
Some other principles I think we may want to address at future
meetings include security standards, development practices (code
repositories, code review policies, etc.), development methodologies,
accessibility, legal compliance (auditing and reporting compliance, e-
discovery, etc.), and interface standards (how much training and
confusion could we save by making new applications look-and-feel like
existing ones?).

One other excellent suggestion I heard after the meeting was to create
a light-weight, cradle-to-grave process for submitting, vetting,
funding coding, testing, deploying and maintaining applications;
basically, having a solid outline for taking something from idea to
reality. I believe the person who suggested it will be posting his own
thoughts to the wiki.

And that's all I've got to say about that . . . for now.

Best,

Jeremy.
–
Jeremy Phillips <jeremy@ucdavis.edu>
Systems Administrator
Center for Mind and Brain
University of California, Davis