Frequently Asked Questions

If you have any questions, please feel free to contact any TAC members or send email to <its-technical-architecture-committee@lists.hawaii.edu>.  We’ll endeavor to document any questions that we get on this page.

Table of Contents

Q: Are there times when I should notify the TAC about my work?

Yes, there are several times it makes sense to reach out to the TAC including:

1) If you’re leading a project that will be deploying a new product or technology.  The TAC can work with you to make sure your project fits into the ITS architecture, or when appropriate, adjust the ITS architecture to address the changers your project introduces.

2) If you’re experimenting with new technology that may eventually be used by ITS.  The TAC would like to keep track of the technologies with which we are experimenting, so we can avoid duplication or connect people together with common interests or requirements.

3) If you have an idea on something the TAC should address. We want everyone to feel some ownership of the ITS architecture.  So if you have suggested changes, talk to any of the TAC members and he/she can bring the issue forward to the group.

Q: What is the role of the ITS Directors in establishing the ITS architecture?

The ITS Directors have asked the TAC to escalate to them any architectural decisions that are felt to be particularly strategic, controversial or have a large impact on the organization.  For example, the TAC escalated its “Patching Principle” to the ITS Directors because the principle could have significant impact on daily operations across ITS.

Q: How is membership of the TAC determined?

TAC membership is made up of the ITS staff persons that generally serves as the primary architects for significant technical areas (domains). Ideally as a group, the membership will be representative of all ITS divisions and will provide broad technical and logistic expertise.

Q: What is a 'lifecycle technology roadmap' as mentioned in the committee charge?

It is simply a document that outlines what technologies we use and how long we expect to use them.  TAC uses a format called a ‘brick’ to define the lifecycle of each technical component. There is more on bricks in the our architecture section of this web site.

Q: How does our architecture effort compare with other universities?

Many large universities have developed fairly large and mature enterprise architecture programs.  “Enterprise architecture” is a comprehensive program that tries to align business needs with technical solutions.   Wisconsin, for example, has about four staff dedicated toward its enterprise architecture.

Here at UH our goals are more modest.  Rather than pursue a larger enterprise architecture program, we’ve decided to focus on the area where we think we have the most need, technical architecture. We hope this gives us the most benefit for a modest investment of our time.

There is a special interest group of higher education architects called ITANA (which is a non-exact acronym for Information Technology Architects in Academia).  Visit their web site for more information.

Q: What is a brick?

Bricks describe the individual components that make up the technical architecture. Bricks identify the planned life cycle for technologies within a each domain. They are useful for anyone who plans on building upon or leveraging a specific technical component.

Practically, a brick is a document that we use to define what technologies we’ll use in ITS and how long we plan on using them.

Q: What is a principle?

Principles are a set of high-level statements that establish certain boundaries and criteria used in the decision making process. Principles define the general rules and guidelines for the use and deployment of IT resources across the organization.  Principles are most useful when design or implementation decisions are being made.

Q: The original TAC charter also mentioned Templates and Designs, what happened to those?

Templates for drafting new bricks and principles are provided in the working spaces for drafts.  Design have been dropped for now since we don't perceive a sufficient return on value for the overhead that would be required to manage implementation documents, which is what designs are.