A mass transit experiment...

My postings are my opinion solely and should not be construed casually or otherwise to be the official writ, opinion or belief of Ball State University, its assigns, or its peers.

I also need to give the BlackBerry disclaimer that this post was written on a bumpy bus ride using predictive text and I haven't had my morning coffee yet, so I apologize for any typos.

I am currently in a shuttle bus heading to the airport for what is going to be basically a mass transit trip. Instead of driving my own car and parking it for a week, or asking for a ride, I wound up catching the shuttle to the airport, where I'll fly out and then land eventually in Rome, where I'll take the buses and Metro for the duration of the trip.

It is a distinctly unusual experience to do this type of travel when, as an American born in a semi-rural area, I was seemingly born with a set of keys in my hand. My standard mode of transportation has been the automobile for most of my life, and now I'm trading time for efficiency/savings.

In many ways this is the situation that we find from an architectural point of view, and I find a gap in the way we address our current architectures.

I rode to the pickup point in a private car - the shuttle transports groups, not individuals - and from there the shuttle's capacity of 24 will bring me to the airport to take a flight holding about 100, that flight will head to an international hub where I'll get on a plane carrying about 200. When in Rome the transport will be packed to capacity, so whatever means is taken will be quite full of people.

My overall point is that our architecture has reached the point where we have been strapping together compact cars (individual PC/servers boxes) in the hopes of creating an efficient mode of transport, but efficiencies gained via speed are being offset by the costs that exist, but are not visible. For example, cooling servers is not inconsequential.

The glue holding the travel I'm doing together is the bus travel. Buses connect with reasonable efficiency the supercenters of real efficiency (the hubs). In the same way, I feel the bus is being ignored when it comes to system design. There is such a focus on doing all things with one thing (Nietzsche would refer to this as the ueber-thing) that no one is asking the questions about using a mass transit model for de-siloed information, allowing well-functioning hubs to do their work and send things through the web services bus.

Perhaps I have sticker shock from having just spent a couple of days with counterparts at other universities and finding out what their actual costs are (n.b. - do not under any circumstances sign a contract for a massive systems upgrade without a couple of field trips to other places already there which include full disclosure of ongoing costs - that could be a project-saver!). However, I feel there is a better architectural way that allows interoperability and prolongs investments considerably when addressing the nerds of higher education.

Instead of having one system that does it all, as long as the all it is doing fits into the framework of what its vendor tells you you will use - customization is often expensive and sometimes not supported - systems could each do what they do best, and transfer information from one place to another via the bus using web services.

Are web services the fastest way to do this? No. In the same way, a bus is not as fast as a car. At issue is not a single piece, or packet, but an overall approach to data use. The benefit to web services is that they remove barriers between systems by placing data in a format that can be easily understood.

There is no panacea for systems design, no magic bullet solving all issues. There is no one best way. However, when we design we should take into account all factors, not just try to fit one design construct.

In my experience, decision makers rely on evaluations from the crowd on how to do things, even though their systems are as individual as their organizations. This is where the competent systems architect must step in to evaluate and recommend that which is more in line with the efficiencies and costs for the organization. It may be what the Gartners of the world recommend, or it may be a structure that takes into account the particular nuances of your computing infrastructure. If your data is ubiquitous, your end systems can differentiate. If your data and end systems are both ubiquitous, you cannot differentiate on the basis of your computing.

Should everyone use a SOA approach? Not at all, and they shouldn't put all their eggs in a CRM or ERP system, either, just because it is a trend. The key is to first know the problem you need to solve, know the existing tools and structure you have, and know the cost of either replacing what is there or swapping out pieces of it.

I'm not getting to the airport when I'd ideally like to, since it runs on a schedule, but I'm getting there, and for a fraction of the cost/hassle of driving. To that end, each person on this bus is catching a different flight, but we are all going to get where we are going, and we didn't have to all dress the same or come from exactly-alike houses to get where we need to be. There wouldn't be anything wrong with it if we did dress alike and come from like houses, there's just no compelling reason in our case for us to have done so. From what I hear, the buses in Rome are overcrowded and unreliable, so there an individual taxi may make sense after I experiment. Time will tell.
Sent via BlackBerry by AT&T