Please report any problems to the Shared Tools Team at    Broken Links? Missing Macros? WIKI Retiring Plugins
Child pages
  • IT Assets Meeting 2018-05-07
Skip to end of metadata
Go to start of metadata

Mon, May 7, 2018, 1:00-2:00, Rm 3139B CS

Wiki page:  
Box folder:  

_x_ Michael Block, _x_ Gary De Clute, _x_ J.J. Du Chateau, _x_ Lea Ericson, __ Rafi Lazimy, _x_ Kristen Mcroberts, _x_ Colleen Reilly, __ Bruce Riley, _x_ Tyler Schultz


  1. Agenda Review / Previous Minutes

    • OK. Please send comments or corrections to Gary.

  2. Review Results of the Brainstorm
    Handout: Brainstorm Results
    • The purpose of the brainstorm was not to re-invent the wheel, but to explore how we think about what is or is not IT.
      • The idea is to craft a definition that parallels how we think about IT, rather according to a more abstract formal taxonomy. (We are trying to make this useful to lay persons, not just IT experts.)
      • That goal does not preclude consulting with formal taxonomies to improve the definition. Perhaps it would fair to say the definition could be improved by formal taxonomies, but not driven by formal taxonomies.
    • The brainstorm results show that we do not think about IT resources in a single hierarchical manner. We think about IT in at least three intersecting dimensions, (more like a matrix than a hierarchy.)
      • by general function or kind (computers, data storage, data collection, peripherals, consulting services, etc.)
      • by specialized type of technology, (Internet, Telecom, IT security, Digital AV, etc.)
      • by specialized use or purpose (research computing, instructional computing, ERP, Electronic Records Management (ERM), etc.)
    • That way of thinking about IT opens the possibility that instead of having a semi-exhaustive list of specific items, we can generally characterize IT resources as:
      • Things of typical functions or kinds, (that people tend to think of as IT functions or varieties.)
      • Certain specialized technologies, (generally thought of as being IT-related technologies.)
      • Certain specialized uses or purposes (generally recognized as using or involving IT resources.)
      • Each of the above has some examples and counter-examples, (the counter examples illustrating what is not considered IT for this purpose.)

    • The team discussed how to turn the brainstorm results in to a definition document.
      • The attached diagram illustrates the purpose and scope of the general definition of IT.
      • The purpose of this definition is to create a boundary for IT, within which the person acquiring or creating hardware, software, or services needs to be concerned about compliance with IT governance policy and procedures.
        • A specific IT governance policy or procedue will have a scope that includes a portion of IT as described by the general definition.
          • There will be probably be things within the scope of the general definition that are not within the scope of any particular IT governance policy or procedure.
        • The intent is that the general definition of IT should be broad enough to include the scope of all the IT governance policies and procedures.
          • There may be a few items within the scope of some policy or procedure that inadvertantly fall outside of the general definition.
            • This is not signifcant problem provided that the omitted items are relatively harmless.
              • The omitted items are easily recognizeable as being within the scope of a policy or procedure.
              • The omiitted items are unusual cases that seldom occur, the omision of which creates only a small risk to the insitution or individuals.
        • The scope of the general defnition does not need to include items that are unlikely to be within the scope of any particular IT governance policy or procedure. 
          • These "false positives" should be a relatively small minority in order to avoid wasting time investigating compliance issues when no IT goverannce policy or procedure applies.
        • Thus, if the item being acquired or created falls with the scope of the general definition, it is likely to fall withing the scope of one or more IT governance policies and procedures. The person acquiring or building the item shoud therefore be concerned about compliance.
      • It is NOT the purpose of this defintion to describe the scope of any particular IT governance policy or procedure.
        • Scoping a particular IT governance policy or procedure is the task of those who are developing it. It is not a trivial task because policy scope needs to precise enough to remove most ambiguity as to whether or not the policy or procedure applies. It is not practical for the IT assets subcommittee attempt that task.
        • If is, however, practical for the IT assets subcommittee to generally characterize what IT is, because for that purpose some ambiguity is acceptable.
    • Tentatively, the definition will be organized as follows.
      1. The text of definition itself.
        1. Use the general definition from the IT spend document from Fall 2017.
        2. Elaborate upon that definition to be more specific about is or is not included. In particular, the remainder of the definition will consist of three different ways to characterize "IT". Each one will be a sentence or two.These will overlap because they are different ways of characterizing the same thing. None of the three will be exhaustive, because that is not practical, and IT is a constantly changing field. In addition, attempting to be exhaustive will make the definition too large and complex for practical use. See the brainstorm results for specific items that could fall under each of the three characterizations of IT.
          1. General functions or kinds of things that are usually recognized as IT.
          2. Specialized types of technology that are usually recognized as IT.
          3. Specialized uses or purposes that are usually recognized as IT.
      2. Examples that support the definition.
        1. The examples will be organized in the form of a table with three columns:
          1. Item
          2. Examples
          3. Counter-examples
        2. The starting point for items in the first column will be (approximately) the main bullets in the brainstorm results under each of the three ways to characterize IT. The starting point for filling in examples and counter-examples will be the sub-bullets under those.  Note that counter-examples are important because there are things that could be consiered to fall within IT in the most general sense, but are not being treated as IT assets or resources for the purpose of this definition.
      3. References
        • Because the purpose outlined above is to create a boundary within which one should be concerned with compliance with IT governance policies and procedures, it will be helpful to list the known policies and procedures that the person should be concerned about.
          • Those listed should be the policies and procedure that apply when acquiring or building hardware, software and services that are within scope.
            • There may be IT governance policies and procedures that regulate other aspects, not directly related to acquiring or building IT assets or resources. Including such references would be distracting and result in too long a list.
        • The list should also include areas of policy and procedure that are not, literally, developed by what we narrowly define as IT governance at UW-Madison, (i.e. core IT leadership, the ITC, the ITSC, the 'TAG's, and related individuals or teams, as diagrammed in the description of IT governance.)
          • For example, there are specific areas of IT have their own governance arrangements such as HIPAA and PCI.
        • The list should also include relevant laws, reguations, or policies that are not specifically addressed by current UW-Madison IT governance policies and procedues. These are things that are within the scope of IT governance, but there is not, literally, a UW-Madison policy or procedure.
          • Examples include relevant UW System policies and procedures or relevant laws or regulations that UW-Madison must follow whether or not UW-Madison IT governance creates local policies and procedures.
            • The fact that UW-Madison does not have a local document does not reduce the need for compliance.
            • There will be cases where there is simply no need for a local document because the referenced documents themselves are sufficient.
        • The references should, whenever practical, provide a local contact point for further information or clarification.
          • Whenever practical, that contact point should be at UW-Madison, rather than sending the inquirer to some third party.
            • Many policies and procedures will contain a contact point, but it is still useful to list a contact so the inquirer does not have to dig through a somtimes lengthy document to find it.
            • Providing a local contact point will be particularly important if the contact point in a referenced document is to a third party, but a more local contact point is available.
    • Follow up.
      • Gary will draft a portion of the defintion as described above, and send it to the subcommittee for review and comment.
      • It will a portion only, at this time, because we want to test the practicality of following the above plan before we invest the full effort in developing the complete document.
      • The team members should comment on the document, and not be shy about pointing out potential issues.
      • The team will consider the resulting comments, and modify the plan as warranted.
      • Whatever we have as of May 18th is what Rafi and Gary will report to the PAT Executive Committee as the subcommittee's preliminary results.

  3. Outside work between now and next meeting.

    • Review and comment on the draft document.
  4. For next meeting on May 23.
    • Review the comments.
    • Further refine the definition.

  5. Follow up
    • We might do some additional follow up by email. TBD.
    • We have a follow up meeting on June 6.
    • On June 15, we'll report the refined definition to the PAT Exec Comm, along with our assessment of whether it is good enough, or needs more work.

Ground Rules

  1. Everyone must be treated respectfully, whether present or not.
  2. Everyone present who wants to speak on a topic must have a chance to speak.
  3. Attend more often than not, and review materials when you can't attend.
  4. Don't be shy, or worry about perception of an idea - we need open borders for these discussions.
  5. Let's park side issues or extensive detail for future work by this team, or others.

Work Plan

  • Initiate Subcommittee. DONE.
  • April 3, Get organized. Have a common goal, and a process to get there. DONE.
  • April 18, Brainstorm DONE.
  • May 7, Create preliminary definition with information from brainstorm

    Deliver preliminary recommendations to PAT EC by May 11. (PAT EC meeting is May 18.)
    Preliminary report may be sufficient. If so, Done. Otherwise:
  • May 23, Refine, as necessary (how is TBD)
  • June 6, Refine as necessary...

    If possible, deliver final recommendation to PAT EC by Jun 13. (PAT EC meeting is June 15.)
    If so, Done. 
  • June 20, Refine as necessary...
  • July 11, Create Final Report

    Deliver final recommendations to PAT EC by July 13. (PAT EC meeting is July 20.)

Future Meetings

Team Members

Michael BlockL&SGary De CluteIT PolicyJ.J. Du ChateauDoIT Architecture
Lea EricksonAccounting ServicesRafi LazimyITC (faculty)Kristen McrobertsStudent Financial Services
Colleen RiellyDoIT PurchasingBruce RileyPuchasing ServicesTyler SchultzSMPH


File Created Comment

General Definition of IT and Scope of Policies.pdf

May 08, 2018 11:29  

  • No labels