Task Force Details | Middleware Task Force | University of Montana-Missoula
The University of Montana
UM Home UM A to Z Index Search UM

Middleware Task Force

Middleware Task Force Details

Problem

To develop an effective process through which the University can evolve its middleware environment, both now and in the future, in the presence of conflicting goals (e.g. those of the central computer system providers vs. individual campus units), resource constraints (i.e., both hardware/software and personnel), technical constraints, and highly decentralized control.

Solution

Create a process consisting of the following parts.

  1. At each major decision point, create a small, focused Task Force charged with producing a Draft Design Report that identifies the subset set of campus goals (requirements), feasible design alternatives, and resource/functionality implications of each alternative.
  2. The Draft Design Report is forwarded to a larger set of technical reviewers, who check and verify the details, then submit written comments (and corrections). From this comes a Final Design Report.
  3. The final report is forwarded, when needed, through the IT advisory committees and senior policy makers who control available resources – these groups select specific design decisions and commit the resources required to achieve and maintain the system that results from that design.
  4. All concerned work together to implement the design – if contention arises over implementation details, the same or a new Task Force can be used in a similar process to identify and resolve implementation issues

That is, it is anticipated that this will be an on-going effort that must be repeated (roughly) every two years as systems evolve. It relies on a campus-wide design team to propose a design acceptable to all campus users, rather than a central (CIS) design team which imposes a design on non central units, and on the willingness of several units (not just CIS) to allocate the time of their technical staff to the global design effort. It separates the identification of alternatives and implications from the resource decisions and value judgments required to select one alternative over another. It assumes that central support for tools, training, and leadership will be provided by the ITO. It also assigns additional roles to a (broad) group of technical reviewers and existing IT advisory committees.

What Needs to be Done Now?

Create an initial Middleware Task Force, chartered to investigate and report on current campus-wide middleware goals, implementation alternatives, constraints, and resource implications. In particular the Task Force needs to consider the challenges including but not limited to those posed in: LDAP and LDAP-based authentication required by current systems; the Active Directory implications of Windows 2000, Windows 2003, Exchange 2000, and Exchange 2003; required interaction between LDAP/Active Directory and IP management subsystems such as DNS, DHCP, and NAT tables; the flow of information from the Banner as the assumed “source” into LDAP and Active Directory; the flow of information and updates between LDAP and Active Directory instances; and compliance implications of personal information housed in centrally or non-centrally managed LDAP and Active Directory instances. In keeping with the general framework noted above, the result will be a draft report that identifies requirements, alternatives, constraints, and resource implications, not a specific design that picks or endorses one set of alternatives over others.

Specific Detailed Task Force Charge (draft). To draft a report for a UM-M/UM computing environment that meets identifies requirements, alternatives, and constraints pertinent to the middleware environment with the following characteristics.

  1. The central UM-M/UM environment holds authoritative information in Banner and other sources, which is then effectively and efficiently “pushed” into critical middleware components that support campus wide name resolution and authentication components (e.g., DNS, DHCP, LDAP, AD, and others) appropriate to support centralized systems (both Windows and non-Windows based) and also provide an environment in which other units can effectively and efficiently integrate their own (Windows and non-Windows) environments.
  2. Multiple options are available to other units in fitting their environments into the central framework, each option having different inherent implications and maintenance costs.
  3. The need to satisfy certification requirements (e.g., FERPA, HIPPA, GLBA, and others) represent real costs to be considered in the maintenance and distribution of personal information in the middleware environment as well as in the application system environment.
  4. A viable technical alternative is neither “good” nor “bad” in its own right, but does carry with it both functional and resource implications.
  5. Besides Banner, integration must be planned for central enterprise class systems including PARIS/Pro-card (Windows), the library system Endeavor (unix), a course management system (currently Blackboard/unix, but that is under review), a variety of unix and Windows email systems, a variety of unix and Windows Web systems, and (at some point) the Campus Card system (unix).
  6. Versions of Windows to be supported include Windows/NT, Windows/2000 (and subvariants), and Windows 2003. Transition paths should be identified as follows: Windows/2000 to Windows/2003, Windows/NT to Windows/2000, Windows/NT to Windows/2003.
  7. Email environments to be supported include the new centralized unix systems; centralized Windows/2000 Exchange system; unit-based Exchange environments running under Windows/NT, Windows/2000, and (eventually) Windows/2003. Transition paths should be identified for Exchange environment in the same manner noted above for Windows environments.
  8. To the greatest extent possible, the middleware design should manage most information in a centralized environment (especially any information subject to certification) but allow information to be carefully distributed to or augmented in unit-based environments to allow units to meet particular instructional, research, or administrative goals.
  9. To the greatest extent possible, the email design should provide a central collection and distribution point where campus-wide policies and services can be applies, but also permit flow to unit-based email environments to allow units with the expertise and resources to manage their own systems to meet particular instructional, research, or administrative goals.

Composition of Initial Task Force

The ideal team is small (5-8 technical staff), yet “deep” in terms of collective expertise and “diverse” in terms of experience and campus affiliation. Staff will be “borrowed” from campus units as required to meet these goals, and with the support of the home unit. Units must be willing to free up a significant portion of their employees’ time during the design, contributing that time to the project. Leadership of this group is critical, given the need to manage a diverse group on a tight time schedule, and to lead the articulation of the design to the rest of the campus. We will ask faculty with experience in IT project leadership and management to serve as Task Force leader(s). We hope to be able to attract faculty to this activity with the promise of minimal compensation, under the premise that the leader(s) can and should treat this as a software design research-in-practice project which can and should produce publishable results.

What is a Possible (Desirable) Timetable for the Initial Task Force?

2003 Nov – Dec Task Force works – produces initial report for initial review (perhaps for a subset of the issues) – opens the possibility of some environment modifications during January 2004.

2004 Jan – Feb Task Force continues work concurrent with expanding campus review of initial design

2004 Mar – Apr Report and campus review complete, including any additions, modifications, or revisions resulting from review.

2004 Apr – May Design determined from report

2004 May – Aug Environment (central and units) upgraded in accord with design

2004 Fall Task Force active if/when needed

2005 Spring Task Force active if/when needed

2005 Summer Task Force reactivated (with updated membership) to prepare for next generation Windows/non-Windows environments

Additional Comments (FAQ)

What does a Task Force do and NOT do?

A task force seeks to understand the ideal goals of major users, merge these all into a single (possibly conflicting) set of goals, identify alternative ways of meeting as some/all of the goals, and estimate the resource implications of each alternative. It does NOT judge the goals of particular units nor does it promote or reject alternatives based on assumptions about resource availability or constraints. It does not always “know” what is technically feasible – when a question arises about feasibility, it does what needs to be done to find and verify the answer. It does NOT make value judgments about “good” or “bad” ways to do things, what units should have as their goals, etc. – it identifies the functional and resource implications of all options and goals. It works to identify the design problem showing clearly what options exist -- it does NOT make the value judgments and resource commitments necessary to determine a specific design.

Who is on a Task Force and what levels of expertise are represented?

Since the primary job for the Task Force is to carefully document the nature of the problem, it must be small (say 5 - 8 members counting its leaders), drawn from a range of campus units, and contain members committed to keeping an open mind on goals and alternatives, carefully documenting its work, and analyzing the problem without succumbing to the temptation to make design decisions based on premature assumptions about resources and “value”. All members need to have a high degree of technical expertise, but none needs to be “the expert” on any topic. In fact, it is critical that everyone understand that X being picked as a member does not imply that X is or is not “the expert” on anything. What is important is the collective expertise of the group in doing its job, which involves much more than technical expertise. For example, a group that is competent and confident enough to determine when outside expertise is needed and seek that expertise without hesitation is likely to be much more productive than one that is reluctant to seek outside help because it feels is must “know” the answer. The Task Force must be able to pool its collective talents, add external expertise, and produce an analysis that can stand up to the scrutiny of other campus (and non-campus) experts.

What else does a Task Force member need?

Each member of the group must be freed from a significant amount of normal day to day duties during the time the Task Force is charged to do its work. For any member that is a classified employee, it is essentially that a temporary reassignment with reallocation of duties be properly documented within the classified employee framework. For a non-classified employee, the equivalent in the form of a memo from the supervisor should suffice.

Suppose I consider myself an expert on the issues at hand and I’m not picked for a Task Force – how should I feel?

Very lucky. You may or may not get invited by the Task Force to contribute your ideas, but if you do, when the Task Force report comes under fire during review (and it will), their names are on it, not yours. And, if you’re expertise isn’t used or you think you see things in the report that are wrong, you’ll be free to “snipe” at the report without having the burden the Task Force faces of trying to solve all the complex and conflicting goals and technical issues. But you shouldn’t feel too comfortable – it is likely that the campus will have to repeat this exercise about every two years, so the next time around there is a good chance you’ll be “lucky” enough to get picked.

Who can be a Technical Reviewer and what influence can a Technical Reviewer have?

A reviewer is anyone who is willing to commit to study (vs. “read casually”) the Task Force report and write up a coherent review of its strengths and weaknesses (vs. verbal comments and flaming emails). The goal of the technical review is to “fix” any and all technical errors, omissions, and misunderstandings, not just collect a bunch of unsubstantiated opinions. Thus, the influence a Technical Reviewer can have depends entirely on the effort he/she is willing to put into studying what the Task Force has done, and carefully (and in writing, so it can in turn be reviewed by others) articulating a particular technical position. If you feel slighted at not being picked for the Task Force this time around, do an outstanding job as a technical reviewer and you are liable to be “rewarded” by being picked as a member (or even a leader) next time around.