Tag Archives: entropy

Top 5 Definitions of Enterprise: focusing on the Enterprise in “Enterprise 2.0″

It’s a cool sunny day in San Francisco and there’s some bustle at the Moscone center.

Enterprise 2.0 conference.

You can tell it’s an Enterprise conference because unlike the Web 2.0 Conference there’s no free pass even to the show floor. Also the full pass is about $2500 bucks. One way to define Enterprise is:

en⋅ter⋅prise
  /ˈɛntərˌpraɪz/ [en-ter-prahyz]
–noun

5. Stuff I wouldn’t do unless you paid me.
crime scene clean up
This definition puts Enterprise squarely in the camp of crime scene janitorial services. It adds a concept of “professional” to the discussion and establishes the Enterprise as the realm of uncomfortable clothing. I recall reconnecting with Arthur Van Hoff after our adventures in Java and having him laugh at me because I was wearing (in his words) an “IQ Restrictor”, his parlance for a necktie. This definition also puts a dynamic tension between the “Suits” at the Enterprise 2.0 conference and the boho hipsters wearing the Emo Hair.

4. Software that sucks.
PHAILBOAT
This was the definition I evoked in my post “The Human Enterprise.” To be honest, I introduced the idea of “The Human Enterprise as a direct counterproposal to “Enterprise 2.0″. I think the piece that was missing from The Human Enterprise is the extent to which fragmentation plays a role in the essential nature of the Enterprise, which is a theme I’ve been addressing more lately in terms of the effect of sheer size on the Enterprise.

3. A venture requiring industriousness or courage.
Kirk
This definition deserves some attention because it in some ways captures exactly what’s missing from the current debate around the Enterprise. The extent to which courage has been slowly sapped by the ravages of the Great Recession and “job security” is to some extent disheartening. In particular, efforts to rejuvenate the complex IT System Architecture and to mitigate the effects of Entropy and the “Heat Death of IT” have been met with cries of “SOA is Dead“. So here’s a call for the restoration of courage in IT, to boldly go. Set phasers on “frappe”.

2. Dead stuff that used to matter
he's dead jim
Rumors of the death of Enterprise Software have been greatly exaggerated (nice post by David Hornik). The thing people find hard to understand about the longevity of most Enterprise IT is that “dead” software actually lives a long time. In fact dead software (nice post by James Governor) runs 90% of the economy. Another word for “legacy” is IT projects that worked. The word for IT projects that didnt work is “consolidation”. This should be especially resonant for folks at the Enterprise 2.0 conference, since 99% of the projects spawned by “Enterprise 2.0″ will fall into the latter category. We will have won when there’s “Legacy Enterprise 2.0″ apps out there.

1. An organization whose mission requires significant size, growth and longevity
I present this as the number one definition in an attempt to extract the most salient feature of the Enterprise to casual observers. The definitionis designed to be inclusive of Government organizations. I don’t want to open a can of worms (big government vs small government) but arguably some “missions” such as the regulation of interstate commerce and providing for the common defense would require a degree of size, scale and longevity. But what’s more interesting about this definition are the implications.

At this scale, the organization struggles with whether it’s “too big to fail” or “too big to succeed”.

The implications of size include fragmentation of organization into tribes.

The implications of growth include fragmentation of markets into niches.

The implications of longevity include fragmentation of technology into silos.

cracked

These forms of fragmentation is the key challenge of Enterprise, and the points that some E2.0 companies seem to miss. Trying to repackage consumer apps and peddle them to Enterprises misses the unique pain of Enterprise. I’ve spoken and written extensively about the effect of technological and organizational silos, for example in my book SOA Adoption for Dummies. But lately I’ve been thinking about the effects of market fragmentation.

There comes a tipping point in any large commercial sector Enterprise where the market for the flagship product or service becomes saturated. At this juncture, the revenue growth challenge becomes less about attracting and delighting new customers but rather about sucking as much money out of existing customers as possible. The example I will provide for you is the Apple iPod. At the risk of offending fanboys, the iPod market is saturated. I must own a half dozen iPods. Now I go running with my iPod nano 3g. When my 3g failed, I went to the Apple store to buy a new iPod. The way Apple segmented their products, they had created a low end model at $59 dollars (the clip) which had no screen, a “medium” range but portable option (the nano) at $150 and then the “platform” model, the iPod Touch at $199.

The nano costs only 50 bucks less than the Touch, but for users who want to run with an iPod, the Touch is too big. Since they overloaded the nano with features I dont want (accelerometer, video camera, FM radio) they were able to jack up the price.

ipod sucks

This kind of behavior exists in many mature markets, including cell phone plans. The cell phone companies have “package designers” who specifically design packages including SMS and email that rack up a maximum number of overcharges and fees. They design packages that exploit the gap between what users think they will use and what they actually use based on data mining in their demographics. This type of behavior makes the Enterprise essentially the “enemy” of the consumer. Of course we want successful companies to have profits so they can fuel the next generation of investment. I certainly want Apple to succeed and I bought their product even though I found it mildly distateful (it was still the best player for my purpose).

I wrote this post in the hopes that it would stimulate discussion about how people define the “Enterprise” in “Enterprise 2.0″.

My 2 cents,
Miko

Posted in Cloud, Enterprise, Nerds | Tagged , , , , , , , , , , | Comments Off on Top 5 Definitions of Enterprise: focusing on the Enterprise in “Enterprise 2.0″

Entropic heat death of IT

I originally wrote this piece in November of 2007. I wanted to revisit it today because of the strong emphasis in the downturn on two major themes:

* Consolidation and
* Modernization

Both of these are ways of dealing with the past–consolidation is a way of rationalizing and reducing the ongoing burden of the past, while modernization is a way of bringing the past into the present.

In any event, these thoughts, penned a few years ago seem to still have resonance for me in thinking about customer problems in large scale software projects.

In reflecting on this post, I think measuring entropy solely in terms of “people” needs to be revised, and virtualization is a good way to ensure that utilization of systems is maximized, therefore maintaining a high level of energy available for work. I think this might be a valid way of looking at the overall IT budget.

Increasingly I’ve been referring to SOA using a folk definition that includes “a way to maximize the business value of the existing and ongoing IT investment”. Keeping that in mind, Entropy is a key variable to watch.

As a final note which I hint at in this piece, the natural conclusion is that if there is no way to reverse entropy, the entire system achieves “heat death”. Another source of inspiration is the evolution of biological systems, where local entropy is reversed through the addition of solar energy. The thing is, we get more and more IT funding and budgets each year (not that the budgets get bigger mind you, I’m just pointing out that there is such a thing as ongoing funding) so what remains is how we apply that funding to the system as a whole.

Now on to the original post:

How is time measured in IT?

The key unit of time in IT is the “project”. Projects are funded, each of which seeks a specific ROI and each project succeeds or fails on it’s own.

How is time measured in Physics?

In Physics, the concept of the “arrow of time” is modeled using Entropy. It’s how we know time is passing, which is the increase in the Entropy of systems. You put a drop of ink in water and it spreads out.

So what can we learn from physics through applying the analogy of Entropy to IT systems?

First of all we must understand what is axiomatic about Entropy:

* Definition: Entropy is the measurement of the energy in a system that is unavailable for work.
* Tendency: A closed system tends towards maximum entropy.

If Entropy is defined as the energy in a system that is unavailable for work, it means that some quantity of your IT systems are unavailable for work. I would suggest that you could roughly measure this by the number of IT persons dedicated to supporting, maintaining, troubleshooting and otherwise babysitting unmaintainable messes left by previous generations of IT projects.

Now you could blame the business projects for causing Entropy in IT systems, but you’d only be partially correct. The mechanism for reversing local entropy is adding energy. You could consider the influx of capital (project funding) to be a way of locally reversing entropy and putting more of your IT systems to work.

The problem is that without a structure in place, the energy is just converted into heat, not into more structure.

Therefore business projects have the potential to reverse entropy locally in IT systems… but it has to be applied correctly.

What I tend to see are Business Projects which are funded and executed without any respect for the implications to IT and I see additional unmaintainable complexity being shoved down into IT in order to meet short term business goals. Some of this complexity is shoved down into offshore teams. This is an attempt to reverse entropy locally within a subgroup. For example, the business team can push entropy to the development team and they can push it to the offshore team. Unfortunately, unless you optimize the whole system towards local decrease in entropy, you will eventually degrade the ability of the entire system to produce work.

This is a perhaps the most important principle in SOA–that unless you’ve aligned your business and IT organizations you will continue to increase entropy in your IT system. The implication is that less and less of your IT system will be available to do work.

This means that eventually IT will grind to a halt.

The organization that is unable to reverse this process will not be competitive.

Posted in Cloud, Enterprise, Nerds | Tagged , , , , , , , , | Comments Off on Entropic heat death of IT