A Face Only a Mother Could Love

Robert Scoble has started an Enterprise Software Foodfight.

The core topic is based around the question of why enterprise software is not well covered by bloggers and journalists.

It looks like he struck a nerve.

I've been mulling over the topic. Given that I spend my days with enterprise architecture, I even considered my own stance on blogging about enterprise software.

There are so many potential reasons. I'm guessing the reasons vary for each blogger.

Perhaps it's because many technical people see enterprise software every day at work, and long to see something with more hope.

Perhaps it's because of the age-old problem of reporting on the hand that feeds you.

Perhaps it's because many (most?) enterprise software vendors don't understand how to operate in the world of blogging. Blogging begets blogging. Press releases beget yawns. Most enterprise vendors are still struggling to internalize the read/write web.

Perhaps it's because readers don't want any more input about products from vendors already bombarding us with information and awareness of the products.

Or...

Perhaps it's because a considerable amount of enterprise software has a face only a mother could love.

Just a thought...

A Weyr of Enterprise Architects

James McGovern' article The One Hundred Enterprise Architects Meme got me thinking on the topic of collective nouns for Enterprise Architects.

A mild stab at Google uncovered

• A mystery - presumes guildsmen or tradesmen
• A glass house - yaya, keep moving
  
• A jealousy - wrong kind
  

Yawn...

Here's some low-hanging fruit off the top of my head.

• A babel
• A governance
• A 3-ring binder
  

To obvious/cliché... keep moving...

Some might suggest

• A superfluity

If you follow the EA blogosphere, how about

• A conversation

Or perhaps

• A code

...

Beyond the Dunbar Number

Stephen Downes delivered another article full of wisdom in The Personal Network Effect.

His ideas on improving the design of social networks are particularly interesting. The basic premise is that's possible to change the point of maximal value in a social network beyond the Dunbar number by increasing the diversity of the network. Highly meshed social networks tend to result in repeat messages. At a certain point, repeat messages lose all value. A diversity in our networks tends to reduce the likelihood of these repeat messages.

This caught my attention after reading The One Hundred Enterprise Architects Meme from James McGovern.

I'm curious if there is sufficient diversity in an aggregation¹ of Enterprise Architects to avoid uniformity.

1. Hmmm... collective nouns and Enterprise Architects - expect a separate posting on this topic.

The Tower is Riddled with Networks

As part of conversation with Tom Haskins and Steve Roesler, Harold Jarche asks What business are you in?

The conversation starts with Steve Roesler descibing a life situation in which his self-employment has probably provided more options than would otherwise be available to corporate employees. In the article, he also related the gist of a conversation with an HR executive. A phrase from that conversation, "This is a business", has sparked an interesting conversation thread with Tom and Harold.

Tom enumerates several excuses offered by business for why companies wall themselves off from networks. At the heart of the concerns is a fear of losing control over their own efforts at perception management.

I particularly like one of Tom's points.

When people say "this is a business" I hear "this is not a viable network".

Harold's question asks us to look at our businesses. Are we in networks or silos?

I’ve noticed that even many so-called “new economy” companies are still based on the command & control models of the industrial age. They’re like dinosaurs wearing mammals’ clothing but they won’t be able to keep warm during the next ice age.

We are indeed creatures of habit.

For what it's worth, we also have so-called "old economy" companies with elaborate informal networks. There are, in fact, riddled with networks. We have good-old boy networks, special interest groups, rumor mills, and leaky channels to outside networks. Are they in fact mammals in disguise? Probably not, but it paints an intriguing picture.

As a change agent, my primary medium of choice is the informal internal networks. This are where conversations take place. This is where pre-emptive consensus is gained prior to gaining official sign-off. This is where the landmines are pointed out.

We're all just making it up as we go along

Harold Jarche posted School, Work & Improv, in which he mentions how his son is excited about an improvisation class.

Harold notes how the non-core school subjects end up being the most important in the long run. He lightly ponders a world where the education system consists of the electives and non-core topics. I will not opine on the education system, but I think most of the disciplines encountered in modern enterprises are sorely compromised by their failure to acknowledge the value of improvisation.

Any discipline not actively embracing the value of improvisation is, in my opinion, on the road to decay. We are deceived, whether by ourselves or by others, if we believe that all things can be planned or written down. Not all problems are solvable. Sometimes we need to fudge it. Sometimes we need to fake it. As long as we acknowledge it, it all has a tendency to work out in the end.

I've always been intrigued with the skills acquires from an intentional study of improvisation. I count what I learned in music improvisation as some of my most valued treasure.

I won't be wrong if you don't talk

A recent article by Tom Haskins, Outgrowing reflexive thinking, explores a barrier to reflective thinking.

This article caught my attention while considering mechanisms used as substitutes for conversations.

Perhaps a penchant for one-way communication is merely one of the defense mechanisms of our reflexive thinking.

ABC - Architecture By Conversation

James McGovern has written a wonderfully thoughtful article entitled Closing Thoughts on the Tulsa Tech Fest.

Among other things, he mentions conversations uncorrupted by canines and equines. He reminds us that discussions of technology should not be distant memories. He reminds us of our original inspiration.

As I read his article, I pondered the topic of conversations.

My first thought was the now commonly uttered phrase

Markets are conversations

To be sure, some might be tempted to convert this into some argument for business 2.0 - a whirlwind of technology for enabling the workers to collaborate share. That's fine, but it's not quite what I had in mind.

As I continued to ponder the topic, I came up with a list which reflects part of the problem.

• Projects are not conversations
• Meetings are not conversations
• Presentations are not conversations
• Email storms are not conversations

Hmm... Too bad we're talking about the lynchpins of modern business.

Ok, so what do other Enterprise Architects do to directly foster and participate in conversations? I am honestly interested in knowing. I'm not just talking about the CxOs and Veeps - I'm talking about the techie types still in touch with the passions of our youth...

Notice: An Update for your Perlang FPGA Cluster is Available

Ok, I've been bit by Tim Bray's Wide Finder meme.

I noticed the conversation swarm as it bubbled up, but didn't pay too much attention. Mark Masterson's article It's Time to Stop Calling Circuits "Hardware" caught my attention, as I have pondered the plasticity of the boundary between hardware and software in a previous life.

So I've been digesting the conversation swarm. It's one heck of an interesting read.

Tim presents a problem case that frames a fundamental shift occurring in modern CPU/system architectures. The shift is moving us away from ever increasing CPU speeds towards ever increasing CPU counts. Certain classes of problems are extremely well suited for the shift to multcpucore architectures. Other problems gain no direct benefit, particularly if they are migrated without change. Tim uses the problem of summarizing log file data as an example of this latter case.

Without brainpower focused on this aspect of the problem, the techniques being employed to increase aggregate compute capacity will not provide much benefit for many of the common tasks performed in IT shops.

There are three interesting aspects to Tim's conversation swarm. Two are explicit. The third is implicit.

The first aspect consists of all the solutions for the stated goal - how to leverage the latest trend in processor/system architectures for the seemingly mundane task of processing log data.

For what it's worth, here are my first thoughts on the problem of leveraging multiple cpus ofor the task of processing log data. My preference leans towards use of existing technology, most likely to be implemented by the people most likely to feel the pain.

Divide and conquer: (the sysadmin in me)

• Coerce the logging engine(s) to dump into multiple log files (to multiple disks or disk channels if necessary).
• Run a pile of processes to process the log files independently.
• Consolidate the data - either as post processing or incrementally via some form of IPC.
• The choice of language is immaterial, but history would probably vote for perl or shell goop
  

This smacks of the type of solutions Tim sees existing in most IT shops. It's blunt. It's probably sufficient enough to allow us to move on the next point of pain. It's almost completely devoid of any interest from a software engineering perspective.

Streams and Trigger: (mentioned in the conversation comments)

• Hook into the log stream(s)
• Spawn readers for the various data collection functions
• Send events from the log stream(s) to the readers, processing the data as it's received

This is generally a solved problem using any one of a variety of existing programming languages/tools.

Neither of these two solutions are particularly interesting, but I imagine they are the most likely to be implemented in the wild.

My final offering is more of a meta solution.

• Formulate a red herring idea
• Pose it to a bunch of brainy people
• Watch them chew on it
• Gain new insight

Oh wait. I'm getting that deja vu feeling. :-)

The second interesting aspect of the conversation swarm is the rumination over the relationship between computer languages and the shift in cpu/system architectures.

One participant (sorry, can't recall the link) offered the suggestion that it's probably easier to improve a language like Erlang than it is to modify the mainstream languages to provide the capabilities inherent in Erlang.

I don't disagree with this point of view, but Tim's point regarding the widespread use of perl/awk/etc points to a fundamental fact in IT shops - the tool must be wickedly effective at getting the job done. Optimal performance is often optional.

So how to effectively use 64-1024 CPU machines?

First off, who says our currently technologies are effectively using the existing architectures? Follow things from the hardware up the application stack - it staggers the mind.

The reality is we seldom go back and fix. We come up with clever ways to incrementally capitalize on architectural changes. We reframe existing code in ways that take advantage of changes in architectures. I'm overgeneralizing somewhat, but no matter.

At the risk of sounding like a pessimist, I think we'll end up with thousands of little SOA web services engines. Each one handling a single piece. Each one with its own HTTP stack. Each one using PHP/Perl/Ruby/etc to implement the service functions. Each one sitting on top of a tiny little mysql database. Eeeep! I just scared myself - better drop this line of thought. I'll have nightmares for weeks.

The third interesting aspect of the conversation is how it shows some of the most important characteristics of the modern concept of networks vs. groups. It's decentralized, it's unlikely to be swayed by an alpha geek, it creates a variety of unanticipated results, it's a bit messy, and it provides fertile ground for exploring the topic at some point in the future.

Good stuff!

Tweet If You're Human

James Governor covers the topic of Twitter banality in You can keep your "Business Language": that's not meaningful conversation.

He reminds us that business meetings are often no more compelling than Twitter tweets on what was consumed for lunch. He also invokes the Cluetrain, reminding us that the marketplace is ultimately a conversation.

I have an additional observation regarding the value of these sometimes trivial conversations.

Humans have an amazing aptitude for extracting information from covert channels. Our daily conversations provide valuable information not normally acceptable via direct questioning. The trivial chatter of daily conversation is one of the basic ways we establish trust for the people around us.

To put it bluntly, any psychopath can mimic the ritualistic protocols of business. It seems to take a real human to sustain the gamut between relevant and trivial interactions over an extended period of time. We use conversation to confirm the humanity and credibility of the people around us.

... whether they come from Twitter or from the water cooler.

(oh, and I didn't have lunch today)