On Monday (April 3, 2006), I was at University of Minnesota presenting on four topics. Below are links to the slides as PDFs:
- UW-Madison’s SOA Migration Strategy – what is it and how do we get one
- Folksonomy and Web 2.0
- IT Architecture – What is it and why 3 isn’t enough
- Identity Management Nouns and Verbs
Note that the Folksonomy slides are from an Internet2 version of the talk and are more inclusive than the slides I used at U-Minn. Actually, I meant to grab these slides not the ones that I used. There are a list of links of the URLs that I used in the Folksonomy demo here:
Links I Use in My Folksonomy Demo
A graduate student at Stanford – Mike Tung – put together a suite of scripts and tools to generate College rankings based on Google searches. He didn’t want to pay for the USNews’ Annual America’s Best Colleges report. Though his work is quite technical, I imagine that it will be simplified into a web app that any student can use at any point in time. “What are the College rankings now?” click…
There are three forces that we can bring to bear to push change to a Service Oriented Architecture.
(1) Architectural Purity
>This is the force of arguing that it is the right thing to do. You can state a lot of reasons why it is the right thing to do like: composite applications, workflow, ROI, integration cost reduction, etc. Basically, you stand on high ground and preach that this is the correct approach. This is a difficult sell to pull off especially in a heterogeneous and feudal enterprise like a higher education institution.
(2) Consumer Request
>This is force of the consumer of the information or service asking for a new way of getting information. The statement goes something like, “I need to know X from your system. I would prefer to get that information in a Web Service rather than a flat file.” The reasons for making this argument may have to do with timeliness of data (it needs to be up-to-date at this moment) or ownership of the business rules (e.g. you have all of the data to determine if X is true so you should just provide the answer instead of sending me the data so I can derive the answer) or possibly wanting to be on the front edge of technology.
(3) Provider Demand
>This is the force of the data provider (or source or system of record) deciding they will no longer support older interface styles (flat file transfers et al) and instead will only support a Web service interface. This argument can bring to bear cost incentives. The provider can state, “if you use the Web service, we will make sure that the Web service is upgrade and updated. If you must have a flat-file, then you must pay for all of the work to develop, maintain and deliver the file”. They can also bring policy enforcement into play. “Any request for a flat-file will be reviewed and you will have to make an argument why you must have the flat file rather than use our Web service”.
The Provider Demand force is the one that has the most weight behind it and is the one that is mostly like to carry day. We can argue about the Architectural Purity of a SOA and we can request Web services but that will fall on deaf ears or at least un-funded ears. When the data providers demand that the data consumers use their Services or pay the bill, then we will see rapid adoption of SOA.
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.
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.
Every so often, I need to list all of the things that I’ve got going on just so I can get a handle on them. This is that list:
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