Jumbled thoughts, it must be Thursday


You run

Monday morning

shaking off the weekend, trying

to find your coffee cup

and Wednesday?

its routine, in the cabinet by the magazines

a coffee cup waiting for

you to pour in liquid morning.

Why Thursday then?

why so lost and jumbled

coffee cup in hand

last drip of coffee falling

to enter the pot

and me

wearing my tuxedo shirt

and wiping the sleep from my eyes

jumbled thoughts

half in the week

half in the weekend

Why, then Thursday?

The last train home, or why is the store closed?

I was thinking the other day about the 4th of July. When I was a kid there was little if anything open on the 4th. It was a holiday that the entire country shut down for.

About 10 years ago fast food and gas stations seemed to start staying open. Now it seems to me that everything is open, 365 days of the year. Even Christmas now has stores that are open.

why is that?

What has changed in our country that we no longer value the time off as much as the convenience of being able to buy snickers bars on Christmas eve?

Living in the virtual world, and I am just a virtual architect.

With apologies to Cyndi Lauper and her much catchier song.

Recently Microsoft released Hyper-V our updated virtual server solutions. It’s made me think about the concept of vitalization.

I equate vitalization to operations. You see, you can’t really virtualize an environment if there are no operations behind the vitalization. You can cut the number of servers you have down to nearly nothing, and yet end up cutting your up time down to nearly nothing as well.

It’s all about operational maturity as you consider "creating" a virtual environment. The first issue is really one that is slipping away. It is the overall issue of performance.

The second issue however remains the operational maturity of the organization. Do you have what it takes to risk your up time on a virtual world?

Over the years I have worked with a number of companies. Many of them have built extensive virtual labs that are very impressive.

  1. They test the solution.
  2. They test their operations.
  3. Then they move the solution to physical hardware.

I’ve worked with other companies who follow a lighter methodology.

  1. Listen to vendor claims, regardless.
  2. Listen to analysts, regardless.
  3. Design a solution that fits your specific one off business needs.

Operationally any one of the above items are a good component of a process, but without testing the risks you run are significant.

I once had a customer that had placed their entire directory structure on a virtual server environment. When I mentioned that solution was even "considered" in our testing and was not a solution we even "considered" supporting, they told me I was saying that because I was from Microsoft and they were using a competitors products.

I argued with them for two days and finally gave up. They asked me to take the section about their directory out of my report and I said, no. Someday this solution is going to fail and frankly I don’t won’t any part of that. They were pretty mad at me – but the reality is, it’s simply not good operations to build your entire house of cards on the edge of the largest fault in North America. There is bound to be a tremor and you have to start all over.

Anyway, my thought is there are three things to consider as you determine if your organization is going to go virtual…

  1. Operations
  2. Operations
  3. Operations

If you have a mature IT Organization that understands and lives by the operational processes and procedures, vitalization may be the best thing that ever happened to your cost structure. If your IT org is immature and not ready for process based computing, stay on the "virtual" sidelines until the mature orgs can build the IT practices you need to be successful.

Better to spent an extra dollar now, then having to spend 1,000 extra dollars tomorrow. (You’ll need those to pay for gas at the pump!)


Laughing, we walked along the street

In summer
with concrete spewing heat
back into the air
on the street
the builders
take what was
and remove it
now no more
pounding and pounding
dust the air
Laughing as we walked
watching the once mighty fall
looking upon the last works
of Osmandius (thank you Percy)!
the last mighty works
that falling
change into birds
and leaping back into the air
gather round us laughing
walking with us with that strange
bird waddle
and stranger still bird
echoing with the sounds
of concrete falling
and heat rising from the concrete
to create a warm front
meeting a hard ground
shattering into
shards that
becoming birds
loop endlessly
in the rising heat
and we laugh
as we walk along the street.

The mirror

The young boy in the mirror
wrestled with his tie
struggling to pull it over his head
and slide it back into place
already tied
already a tie
already a boy
the mirror
an image of the wrestling match
tie pinning the boy in the
first round
running around the gym
arms raised up in the air
boy, sad
face long and heavy
trying to smile
trying to again
the tie.

Can a solution exist in the technology world that doesn’t require an architect?

I’ve thought and asked this question a number of times in the past year. In the technology or software architecture space, is it possible for a solution to exist that doesn’t require an architect?
The question stems from the concept of "solution maturity" or can a solution mature to the point where it no longer requires guidance or integration?
Let’s start with the three tenets I am proposing:
1. Solutions in and of themselves have no integration points. They merely take a set of functional components and "join" them into a coheasive structure.
2. Architects provide or repret the glue between the "solution" and the "organization."
3. There are/are not mature solutions.
Number 1 represents a lously coupled definition of solutions. They, solutions, represent a series of component pieces that have "integration" points within the solution. I like to think of this as making home made ice cream. You add all the components together for the ice cream. Then you add a third party component (the churn) that represents the integration tool. Within the solution (ice cream) the components are integrated. Separatly they are not integrated. Additionally the solution "ice cream" may not be compatible with other desert solutions. It may not even be compatible with the consumer (diabetics etc or those who are lactose intolorant).
Architects (or in this case chef’s) ensure that the overall solution "ice cream" is compatible with the overall organization (ie don’t use sugar for the diabetics), (don’t use milk for the lactose intolorant).
The last components or tenet is the concept of the existence of a mature solution. In the case of ICE cream we could in fact argue that as a mature solution (it’s been around a long time) we should be able to say "anyone" can consume it. But we have the two groups above upon which the consumption would have an adverse affect.
The tenet then would be, would the mature solution "new ice cream" be able to on the fly deploy itself for people that like Ice Cream, diabetics and lactose intolorant people, taking the shape their specific infrastructure requires?
It’s a question that troubles me…
Sadly after nearly 20 years in the IT world, I hope the answer is yes a solution could mature to the point where it no longer required an architecture.
I also know that it isn’t viable right now.
Gotta run – my ice cream is melting.