On IT Architecture:

We don’t have a concise “Contact the Architects when…” document but here is some stuff that has coalesced over the years.

From Jan 2003 retreat – we defined IT Architecture this way:

1. Pattern recognition (we look for patterns that evolve out of various projects and activities).
2. “Good stewards to the ecosystem, midwives to positive evolutionary advanceâ€?
3. Topic sorting (Policy from Technology)
4. “We don’t draw the boxes, we draw the lines between themâ€?.
** We don’t pick the objects but we help define the interfaces (integration patterns).
** We don’t pick the projects but we look at the larger way the projects connect.
5. Conduit of communication. (We try to make sure the correct people are in the room)
6. Breadth of planning. (We get the team’s head up out of the trench)
7. Feelers to the big world. (We pay attention to other things like I2)

I get involved in a project when one or more of the following are true:

1. The system will be enterprise data or business processes source. Then I see working on those enterprise data definitions and standard interfaces for exposing the system.
1. The system will be a consumer of enterprise data. I try to work for a common way of consuming the data – creating a more generic interface rather than another specialized interface for just this system.
1. We will need new enterprise definitions (like new role definitions, or new ways of representing course data).
1. The project sounds like something that someone else is working on. If so, get involved until you see how the two pieces fit/align/collide.
1. The system represents a new piece of the over-all infrastructure. I get involved until you see how it fits, to check if there is duplication with another system, to make sure that the requirements for the system are holistic and well formed.
1. There is an opportunity affect change (on the infrastructure or processes). If so, is it a place you want to apply force (to change a practice or try out a new method or develop a policy).
1. The group that is running the project know for past bad behavior. If so, try to get involved just to keep track of them.
1. There a high risk of confusing campus or stake-holders. Make sure that there is good communication, appropriate requirements, etc. (An example of this was a recent pair of projects: The Registrar was starting up a self-service electronic grade submission project at the same time our learning technologies people were working on integrating Desire2Learn with the Student Information System. Both were calling their projects eGrading).
1. The project needs a neutral facilitator who can capture requirements, next steps, etc. I get involved in some of these as a facilitator.
1. The project needs a creative way of representing flows, doing analysis of the issues, etc. I get involved in some of these to bring in my tricks and techniques for documenting and doing analysis of the issues.

Finally, here is a piece on our IT Architecture Realms of Work