What once was, will be again

I’ve loved that line from “Welcome back Kotter’s” Horshak for years. It is truly what happens in the IT world I live in. Things that were passe two years ago are once again sought out and dignified as solutions. Things that are solutions today will be thrown away. On-Premise becomes cloud based and so on.

The world of IT is a changing world. But why has IT become so disconnected from the business? Why do we have solutions that seek sponsors, rather than sponsors in the business seeking solutions?

We are the little lost kittens who have lost their IT mittens.

And now we shall have no blackberry pie.

Why?

Is the reality of IT that we are no longer a part of the business? Or is it that we in IT have lost our way and have forgotten out to get out of the garden?

.Doc

For Leslie O. Ralstin

I do not often combine my two blogs with one entry. But honestly I don’t lose someone like my Father-in-law every day. He died last evening. The world is a smaller and colder place because of this.

He served in world war two as a signal man on an LZ. He worked for Indiana Bell/AT&T/Ameritech for over 40 years. He played golf and read books to his grandchildren.

The story that means the most to me about him is the story of playing golf in Arkansas one sunny afternoon. We were playing with two of his friends and he was winning the game by a good 10 or 15 strokes. We all came to the 15th or 17th hole I don’t remember which one actually. It was a recreation of the famous 17th at Doral so I suspect it was the 17th hole. The first three of us in the foursome hit the ball into the water. We were giving my father-in-law grief that he would hit the water as well.

He hit the ball right into the water as we projected. However he actually hit the underwater concrete drain for the bond (about 2 inches underwater). His ball bounced off the water and onto the green where he birded the hole. But right after the shot he turned to all of us, we all said “lucky shot.” He said “that was skill boys,” I’ve been laughing about that with him for 18 years. Now I am laughing alone but I am still laughing.

He had a wonderful sense of humor, and was an incredibly playful human being. Its sad for me, I lost my father’s father when I was eleven. Now my sons are 11 and they are losing their grandfather as well.

To Leslie Ralstin, may god hold you in the palm of his hand.

.doc

The plan, the process and oops

Building an architecture plan is something I love about my job. I love pulling together the technical pieces of a solution and featuring them in a series of critical decisions. Taking end user and business requirements and making them into a solution is a huge and fantastic process.

The process is a little different at times however. I’ve read the fantastic bible for creating architectures, “Documenting Software Architectures” by Paul Clements (Len Bass et al). The process itself is simple and really isn’t anything to be worried about. The issue is of course the process doesn’t always map your personal style.

The oops comes in the fact that often people do all of these things, building glorious paper architectures that in fact are never read. That becomes a huge issue, something that drives us as Architects to pull our hair. We create perfection and then no one ever updates what we did.

The plan builds from the process to beautiful documents that placed in 3 ring binders and, oops never read again.

.Doc

Is there a pattern for data management?

While data management is a process (rather than a procedure) it would be interesting to see if in fact there was a logical pattern that could be applied to the concept of data management.

1. How long should the data live.
2. SHould the data have expert qualification?
3. SHould the data be presented in a different format?
4. Can we maximize a process through the application of the data?

At some point everything has to come from somewhere – that first idea, the fresh way of doing things may in fact be sitting on a napkin in your cafe! The more we can do to maximize the ability of users to communicate and publish – the better our solution will management the data within.

.Doc

What is your intent?

Communication is the concept of cutting to intent. Ok that is an over simplification but it is fairly true as well. The concept of “intent” really drives what and how we communicate.

With intent we also have to think about the concepts of what else is out there as far as potential meanings for what we are saying. The part of intent gives you the “reason” to evaluate how your audience will recieve your message. You see if you are talking just to fill dead air, you don’t have intent and you frankly really aren’t communicating.

But with intent we have something we are tyring to “convey.” That message can take any number of forms but our goal is to push it out, bridge the gap and move forward with communication.

Intent. Its a funny word that isn’t often put in the same sentence as communication, but it may be the driving factor.

.Doc

Live Mesh – great tool

Recently i’ve been using Live Mesh more and more. The ability to connect PC’s across securitydo mains (home and work network) to sync non-critical data has been a great tool. I don’t think I would put sensitive data on a solution that relied on a single password, but for what I use it for it’s quite nice. But from a what are you going to do when you connect to the cloud basis it seems to be a very useful tool.

There are a couple of net new features I would like to see however:
1. Support for ORB publication
2. Supoort for WHS devices in your live mesh (you can do it, but I am looking for full support)
3. Support for full windows media center devices (so you can share recorded tv etc)

But for what I am using it for (saving pictures from my cell phone) and personal documents/whitepapers I am working on its a great tool.

As a solutoin for cloud computing it really does help you take that first step towards cloud solutions. It does call to mind the need for a data coverage pattern, but that is for later.

.Doc

If an architecture was a fish and an architect a fisherman…

There was a famous interviewonce where Barbara Walters asked Katherine Hepburn what kind of tree would she be. For me, I’ve often thought of architectures as fish. Each type of fish in a lake has a specific purpose and process. Of course that makes the architect a fisherman!

Catfish are the bottom cleaners – but they are also the base of the overall food chain. They keep the bottom flowing, and produce a lot of smaller babies for the predatory fish. They represent the overall infrastructure plumbing type services such as network, routers and naming services.

The next layer up are the cleaners, or Carp. These fish keep the system moving and cleaned. I compare them to the operations teams that architects have to interface with.

I could go on and on with the comparisons but the next couple of pieces are also important. What type of fisherman are you…

1. Catch and release – use what you need and put the rest back for the next person.
2. Rip and replace – take all the fish you catch and replenish the lake each year with fingerlings.

What kind of architect are you?

.Doc