|
David, et.al.,
This thread, and the inaugural meeting of the SSWG today, is very timely - I've just come from an MIV "tracking" meeting where we discussed how the Kuali workflow engine must be configured to address the situation of clustering of administrative units - specifically how organizational "affiliation" of reviewers and initiators can no longer track with their "home departments," nor provide the attributes upon which to infer roles and responsibilities.
As the clustering of administrative functions becomes more pervasive, this will certainly need to be addressed for a number of IT systems - MIV, People Admin, Kuali Coeus, Banner, etc. This consideration also has significant implications for the Sun Identity Access and Management system we are currently partnering on with the UCD Health System.
Let me suggest this is an important topic for the SSWG to take an early swing at - while there may be plans for "short term" fixes and workarounds, having a cogent and shared architectural vision for our "end game" will be essential.
Thanks
Dave
From: owner-sswg@ucdavis.edu [mailto:owner-sswg@ucdavis.edu] On Behalf Of Tom Wiley
Sent: Tuesday, November 24, 2009 9:13 AM
To: David H Walker; Jeremy Phillips
Cc: Software Standards Work Group
Subject: RE: Thoughts about application platforms
All,
I'm finding that these thoughts and David's draft lead us to Service Oriented Architecture approaches, which we are beginning to look at here. I'm thinking about reusability, abstraction, autonomy, loose coupling, and many other design standards. However I think it would be a good start to identify services on which we want applications to standardize - CAS, Kuali Workflow, (Kuali Service Bus too?). There are probably many others of which I am not aware.
To Jeremy's point, I agree that this group could identify services that 'someone' could develop for the common good.
See you soon,
Tom
Thomas Wiley
Director, Information Technology
UC Davis Extension
1333 Research Park Dr
Davis, CA 95618
530-757-8637
From:*owner-sswg@ucdavis.edu [mailto:owner-sswg@ucdavis.edu] *On Behalf Of David Walker
Sent: Tuesday, November 24, 2009 9:05 AM
To: Jeremy Phillips
Cc: Software Standards Work Group
Subject: Re: Thoughts about application platforms
Jeremy,
I agree. Tom Wiley had suggested something similar a couple of weeks ago, although in much less detail.
I started a page on the wiki to list potential future activities for the SSWG:
https://confluence.ucdavis.edu/confluence/x/wAxdAQ
Feel free to add or amend. I've cc'd the rest of the group so they know about this, too.
David
On Tue, 2009-11-24 at 08:08 -0800, Jeremy Phillips wrote:
Hi David--
It occurred to me this morning that another area where this group could be immensely helpful is in identifying common middleware services that would make developing applications for the campus easier.
One good example is validation and approval workflow for DaFIS accounts. Many (many) applications-both central and internal to departments-need to be able to validate that a real DaFIS account has been entered in the correct format and initiate an approval workflow for charges against that account.
The needed workflow falls outside of the existing DaFIS workflow because, quite often, the DaFIS account managers are NOT the people with approval authority on the account. For instance, it's common for an MSO or business officer in a department to be the DaFIS account manager for grant-funded accounts, but it's really the PIs who have the authority to approve expending those funds.
Furthermore, PIs often want to be able to re-delegate purchasing authority up to a specific dollar amount and for a specified time duration out to their employees (lab managers, research scientists, collaborators, etc.), so providing an interface accessible to account managers and delegates (hopefully via the standard interface to the role management system) to allow for account re-delegations would be necessary.
Providing this as a central service that could easily be integrated into applications would greatly simplify the job of creating applications that need to move money around the University.
Obviously, this is just one example. But I'm betting the SSWG could easily brainstorm more examples.
Best,
Jeremy.
On Nov 23, 2009, at 3:34 PM, David Walker wrote:
Thanks, Jeremy. I'll make these changes and send the URL out to the group.
Also, I agree about needing for classification of the other issues. By the way, I debated whether to include them, as they probably won't end up being discriminators among the likely platforms. If that turns out to be the case, then they become "things we'll need."
David
On Mon, 2009-11-23 at 15:03 -0800, Jeremy Phillips wrote:
Hi David--
This looks like a great start for organizing the discussion. I'm really looking forward to it.
A few thoughts:
* It might make sense to either explicitly define "platform" as a combination of hardware, OS, and software--or to think of it terms of a stack. My concern, for instance, is that choosing .NET automatically implies the OS and hardware architecture, whereas choosing ColdFusion allows (almost) all elements of the stack to be flexible.
* For the "other factors" list, I think one of the first tasks will be to define a scale for each, e.g., public data through highly classified data for the sensitivity column, with solid definitions of what each step along the range means.
* I think it's what you're intending in the "Things We'll Need" section, but it seems to me that one early deliverable from the workgroup should be a catalog of resources pointing people toward the appropriate middleware system AND documentation on how to integrate with it. That's what we started to do on the TIF-Infrastructure website, but that effort lost momentum:
http://tif-infrastructure.ucdavis.edu/for-developers
See you tomorrow!
Best,
Jeremy.
--
Jeremy Phillips <jeremy@ucdavis.edu>
Systems Administrator
Center for Mind and Brain
University of California, Davis
On Nov 23, 2009, at 1:49 PM, David Walker wrote:
Jeremy,
Here's the URL I mentioned on the phone.
https://confluence.ucdavis.edu/confluence/x/bgxdAQ
Thanks for giving a quick look.
David
|