Tuesday, October 26, 2010

Random, Obscure, but Hopefully Funny...

With the advent of the zettabyte, here are some predictions of what would be suggestions from notable people for its name: 

Clive Barker - Cenobyte
Stephenie Meyer - Lovebyte
Mike Tyson - Take-a-byte
Carl Sagan - Billionsandbillionsabyte
Peyton Manning - Reddogrunrabbitleftbankingpterodactylwithorangepreservesanrelishontwohuthuthut[foot stamp]abyte
Jerry Seinfeld - Yaddabyte

Monday, October 25, 2010

Live blog from the IOD 2010 conference

Top 3 concerns of CEOs globally:

1) creative leadership
2) reinventing customer relationships
3) building dexterity (going global)

Factoid: by the end of 2010 there will be an estimated 35 zetabytes of data in existence.

WOW-oid: Avis Europe reduced marketing costs by 50% through better BA-assisted targeting

WOW-oid 2: State of NY since 2004 saved 1.2 billion on questionable tax returns

WOW-oid 3: Jewell Rubbermaid increased the speed of queries 30-50x with a move to DB2

Three ways to respond:

1) Plan an information agenda
2) Master information by making it accurate, relevant and governable

3) Apply business analytics

3 things we will see

1) information will come from everywhere
2) radical flexibility
3) scalability to handle real time processing

Really good point: don't just focus on the info you have, focus on what you need

WOW-oid 4: VISA processes 10,000 transactions per second, in real time

Great to see a credit card company and an energy company using the same types of technologies.

-personal drum beating in 3-2-1...
This all underscores the theme of  the new economy. We don't mainly build, we mostly coordinate the data that wraps around the things we build.  It is long past time for us to realize that and stop making IT decisions as an afterthought.  I call the way a lot of those decisions are made the "full-color, glossy ad-based shoehorn method." It is not enough to decide technology should be purchased, the execution must also come into play.

-end the drumming -

Everyone has a software agenda, but it needs to include the information, not just the software.  My analogy is a plumber buying wrenches. That's nice,  but if the pipe is a 1" pipe and they bought a 1/2" wrench because it looked nice. The new tool will never help direct the stream properly.

Good stuff.

Monday, May 17, 2010

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