Tag Archives: ITArchitect

Printable CEO – cool but how to implement

I came across a post on Lifehacker on the Printable CEO. Printable CEO uses a set of goals which are weighted with points. You then set up your Task List based on how they align to those goals. Then you can say, “I want to accomplish 20 points of stuff this week”. You can do two big items or 20 smaller items. David Seah’s list is very business oriented.

I think this is pretty cool stuff. Especially when tied with the PocketMod idea. PocketMod’s are small booklets you make from a single 8 1/2 by 11 sheet of paper.

So the questions are: could we I alter the goals of Printable CEO to represent I.T. Architecture goals instead? How do we give points to those goals? How would we categorize and measure our tasks? Need to put some thought in on this.

Xythos goes Open Source

I just returned from EDUCAUSE where I met with several people from Xythos. Xythos has just announced Developer at Xythos – a collaboration web site aimed at helping users do creative things with the Xythos software. Kevin Wiggen, the CTO for Xythos, also announced a new initiative to spawn open source development around the Xythos API.

Continue reading

On I.T. Architecture

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