Tag Archives: silos

The Enterprise 2.0 Crock

I think it’s great to have a panel called “Is Enterprise 2.0 a Crock?” at the Enterprise 2.0 conference. Much like SOA conference panels addressing “Is SOA Dead?”


Dennis Howlett posed this question in his blog, entitled Enterprise 2.0: What a Crock. The summary paragraph is quoted here:

Like it or not, large enterprises – the big name brands – have to work in structures and hierarchies that most E2.0 mavens ridicule but can’t come up with alternatives that make any sort of corporate sense. Therein lies the Big Lie. Enterprise 2.0 pre-supposes that you can upend hierarchies for the benefit of all. Yet none of that thinking has a credible use case you can generalize back to business types – except: knowledge based businesses such as legal, accounting, architects etc. Even then – where are the use cases? I’d like to know. In the meantime, don’t be surprised by the ‘fail’ lists that Mike Krigsman will undoubtedly trot out – that’s easy. In the meantime, can someone explain to me the problem Enterprise 2.0 is trying to solve?

Now don’t get me wrong, I believe there are legitimate technologies that can help organizations collaborate and gain significant advantages. But the Enterprise 2.0 crowd for the most part do not show the kind of sophistication about the Enterprise that is needed. OF course there are many many counterexamples of people who are very sophistcated, @ITSinsider @Nenshad @PhilWW @Mastermark and others.

But when I hear panelists say things like:

* The way that business is organized is fundamentally changing, period
* we are breaking down silos
* I don’t know who goes into offices anymore
* Email “reply to all” costs $250,000

I really wonder if there’s enough healthy debate on this topic. It would be nice to see @dahowlett on the panel.

The concept that Silos are something that can be “broken down” shows the ignorance of the people saying it. I wont point a finger at the panelist who used the phrase, and I hear people saying this throughout the conference. But this is a completely wrong concept, and dangerous.

Silos, both organizational and technological are an emergent property of Enterprise. As I defined earlier in the week, the Enterprise can be defined as an organization whose mission requires longevity, size and growth. Longevity creates technology silos, growth creates organizational silos.

Christopher Allen cites Robin Dunbar very well in this post about the famous “Dunbar Number.” We are hitting fundamental limits to human social scalability in the Enterprise.

Until Enterprise 2.0 folks gain a deeper understanding of the day to day reality of the Enterprise, this will continue to have a superficial impact on the Enterprise. If we look back at Enterprise 2.0 in 20 years and can see lots of Enterprise 2.0 “legacy applications”, we can consider this effort to have been a success.

Posted in Cloud | Tagged , , , , , , , | Comments Off on The Enterprise 2.0 Crock

Enterprise Cloud: Why Size Matters

One of the biggest issues in speaking of technology trends is the natural impulse to apply a “one size fits all” approach.

People talk about technology the way they talk about the weather–it’s something that affects everyone the same way. Raining? That’s too bad about the ball game. Nice for your flower garden though.

Unfortunately, when it comes to technology, it doesn’t affect everyone the same way. At the risk of losing 90% of my readers in one go, I’m going to dust off one of the great evil words in the technology industry–Enterprise. As I’ve said before, the word “Enterprise” in the phrase “Enterprise Software” has come to mean software that sucks. In fact, if you Google “Enterprise Software” (with the quotes) the number two link is “Why Enterprise Software Sucks“.

So why dust off this word? I suppose I enjoy collecting antiques.

It’s after all a perfectly good word, and can be repurposed as a pot holder or maybe a tea cozy. What I’d like to have is a word that signifies the following:

An organization that has grown in size to the point where the old tricks don’t work anymore.

Funny Pictures

* Its organization has shattered into factions
* It’s technology has separated into silos
* Its market has fragmented into niches

The big challenge is how does one maintain the advantages of size and scale but still retain agility?

I think it’s possible:
Bull headstand

So how does fragmentation affect the use of cloud?

Well in terms of complex demand, cloud principles are very exciting.

swiss army

If your market is fragmented, you will be happy to offer a platform of reusable services that can be customized by channel partners or even by end users into thousands of possible use cases. Think iPhone App Store. So for complex demand, the cloud is a good thing.

The challenge for the Enterprise and cloud is the concept of “Complex Supply”. Since both the technology in the Enterprise is already siloed, adding cloud just adds another silo. Legacy Mainframe apps, Web Application Servers, Enterprise Applications, you name it, Cloud just adds yet another technology silo to maintain, integrate, secure and govern. Since large organizations are fragmented into smaller organizations, this problem is compounded when one organization creates a dependency on cloud services without a systematic enabling architecture.

Size matters. People try to apply architectural patterns and software solutions as if they were one-size-fits all.

ass is too small

Posted in Cloud, Enterprise | Tagged , , , , , , , , , , , , , | Comments Off on Enterprise Cloud: Why Size Matters

ESB Hate Storm

Lots of hate for the ESB lately.

Everything from Joe McKendrick’s E-s-Busted to Dave Linthicum’s ESB Hurting SOA, we are in the midst of a full-fledged backlash.

I’m certainly sympathetic to these views. The SOA “patient” is already pretty sick. Years of Tribal IT battles, “quick fix” technology solutions that dont interoperate and create more hassles than they fix, project funded IT driven by inconsistent objectives and just plain years of abuse. This after years of “waxy IT buildup” leaving the communications “arteries” of the company rigid and atherosclerotic. Business units are demanding solutions to Business Process problems and quick fixes that existing IT infrastructure can’t support.

Any “expensive cures” for this patient steals valuable money from proven technologies that might have a chance to save the patient. So if some vendors have exploited the pain of this sick patient, I can see why there’s so much anger in the blogosphere for this approach.

The big problem with ESB isnt that it’s of no use. as Lori MacVittie pointed out, ESB exists for good reasons.

The big lie:

The problem is that ESB by itself was sold as a “magic cure” for:

1) Silos, and

2) BPM (Business Process Management)

So along comes this “doctor” called Enterprise Service Bus. All you have to do is take the magic ESB treatment and years of architectural degeneration will be cured… right? Wrong! And the backlash against the ESB “quack doctor” begins.

The “Magic Cure for Silos” Enterprise Architects Rejoice!

Why are people so angry about this? Well, first of all, the ESB “doctor” is guilty of some amount of malpractice. The word “Enterprise” as applied to Enterprise Service Bus is really as descriptive as adding the word “Enterprise” to any piece of software that isnt Enterprise just to make it sound more serious. See, the problem is that this “Bus” wont take you downtown. It wont take you out to the suburbs. You have to change busses 10 times just to go down the street! Proponents of the ESB originally sold the “bus” as a single conduit that ran all the way across your enterprise. Frankly, this just never happened. Getting business units to “standardize” on a single vendor for ESB just hasnt been realistic. Why is this? Because every vendor has an “ESB” and some vendors have 3 or more ESBs (!) So you have an ESB slabbed on top of your Enterprise Apps from Oracle or SAP. You have an ESB from your app server vendor. You have ESBs from your integration vendor. So you end up with a half dozen different brands of ESB all over the place. So people are angry because the “Enterprise” in ESB never happened. This basically means that business unit silos are unaffected by ESB for the most part. All sales teams look for the “Enterprise License” for the products, so why not try to sell your product as a solution for an “Enterprise-wide problem”.

The “Magic Cure for BPM” Business analysts Rejoice!

The second expectation that really wigged people out was the concept of Business Processes orchestrated on top of an ESB. People had this great concept that you could take an ESB product to a business person and some standards based orchestration language like BPEL. BPEL was oversold, I think it must have been the “Business Process” in “Business Process Execution Language” that fooled people. Setting the expectation than an ESB by itself can solve the BPM problem is just naive. If you peel back the onion and look at “orchestration” flows within the ESB, you are looking at integration-logic, not the kind of logic that business people use to solve business problems.

So what’s the reality here? Reality is that you need to accept the fact that, while useful, the ESB was never designed to solve either of those problems. If you were conviced those problems would dissappear when you bought your ESB, sorry guy, you should have read the fine print. ESBs are actually pretty handy for solving integration problems. Should we throw out our ESB? No–just because an ESB is a poor environment inside of which to do BPM and a poor environment to eliminate Enterprise Silos, it happens to be a good environment within which to implement “Business Services”. Don’t think of an ESB as the thing ABOVE the services playing any kind of architectural role: think of the ESB as another kind of app server, and therefore a place inside of which you create and implement a service. Is BPEL a reasonable choice for implementing a service? It’s a little functionally limited, but sure, you could do it. So if you put the ESB in its proper place BELOW the business service interface, you can be made happy again. Leave the Enterprise Architecture and BPM to the other systems please.

So how do we go forward from here? Well, first of all give up on solving Enterprise Silo problems by either forcing a single brand of ESB across all silos or trying to program BPM in your ESB. There is no magic cure.

The (non magical) Solution

If you want to solve the problems of Enterprise Silos, you need a way to federate policy and enforce it across silos. This is what SOA Governance solutions ought to do. Get a SOA Governance solution. Is this enough? No! You also need Enterprise Architecture competency. You need a SOA Competency Center. You need to actually do the work.

If you want to solve the problem of BPM, get a BPMS. Will that please the business by itself? No! You also need to align processes with IT capabilities (services anyone?). You need to ensure that process models can be monitored with a Business Activity Monitoring (BAM) solution and you need to make adjustments (process optimization) over time. You need to do the work.

Sorry, like heart disease, you may need to make lifestyle changes. The shiny ESB you bought unfortunately wont get you all the way there. No wonder you’re mad.

My 2 cents,


Posted in Enterprise | Tagged , , , , , , , , , , , , | Comments Off on ESB Hate Storm

Entertaining and heartfelt post about REST

I like the passion, style, and urgency of this post and concur that IT is going through a pretty major upheaval right now.

Let me start by saying that IT is dying. No, Nick Carr did not kill it. No, it is not dying because “It does not matter”. It is dying because IT can’t do its job. IT can’t do it’s job because ever since we left the mainframe era IT has been served sub-optimal technologies, developed in a hurry by people largely incompetent (on the business side), sometimes simply greedy, that didn’t give a damn about what they were chartered to do. 90% of the people I met on the vendor side match this description.

Good stuff. =)

While applauding the tone, major themes and style of this post, I wanted to comment that it’s hard to imagine a different outcome for IT… Enterprise IT is an evolved information system (as is the brain), and we see layers and silos in the brain also–and we see non-adaptive behaviors (madness, mayhem, murder, suicide, etc)

Recall that an evolved system is subject to the constraints of
* Conservation
* Variation
* Fitness
Essentially meaning that we never throw away anything that performs a function (even if it performs it in a messed up way). We tend to try out a lot of very different things to see what works best, and we tend to compete for resources using all kinds of different strategies.

I realize that mutation and natural selection is somewhat “random” and we could hope that Enterprise IT would “evolve” in a way that was a bit more rational. But lets be realistic–most Enterprise IT systems have a long life span that stretches across many different people’s employment. People come and go, messed up legacy IT stuff sticks around.

So an honest look at Enterprise IT certainly shows that it appears to be deeply messed up from the core all the way out. You could say the same thing about the deeper parts of the human brain responsible for tribalism, me-first-screw-you survivalism, aggression and violence, inappropriate sexual behavior and other primitive impulses. But given that we are where we are, what’s the best solution to evolving our way out?

My 2 cents,

Posted in Enterprise | Tagged , , , , , , , | Comments Off on Entertaining and heartfelt post about REST