Thursday, October 20, 2005

The Man In The Web 2.0 Mask

In the last post I discussed the social pressure behind technology acceptance and technological decision making. To the already long enough list of social pressure sources, a new channel was recently added – the Web 2.0 with its "folksonomic blogo-podo-sphere" – a new viral marketing streamed to your laptop in real-time. Yet this time it's for the people, by the people, and it is so stylish, kewl and ubiquitous that the boundaries between the medium and the message become blurred.

Take, for instance, the opening page of O'Reilly Network from October 15th (Unfortunately, they'd changed their site content. I tried the Internet Archive, but got a message saying the O'Reilly Net is blocking robots – so you'd have to believe me for what I'd tell…). The opening page of the site figured two big boxes, the first boasting O'Reilly's "Distributing the Future", the second stating something like: "Learn Why Ruby on Rails is So Great". If Tim O'Reilly, "Father of the O'Reilly Radar", distributor of the future, and the patron of Open-Source-Emerging-Technologies says that Ruby on Rail is great, what should I think? Does this I of mine has any right to think at all? Is my thought relevant?

Marshall "The Medium is the Message" McLuhan described the above situation as follow:
"When things come at you very fast, naturally you lose touch with yourself. Anybody moving into a new world loses identity...So loss of identity is something that happens in rapid change. But everybody at the speed of light tends to become a nobody. This is what's called the masked man. The masked man has no identity. He is so deeply involved in other people that he doesn't have any personal identity."

McLuhan, quoted in "Forward Through the Rearview Mirror: Reflections on and by Marshall McLuhan", by Paul Benedetti.

Web 2.0 is THE new medium and undoubtedly it is coming very, very fast. It has already infiltrated so profoundly into our lives and people do get deeply involved in other people by this medium - after all, the "participation age" is its motto.

Truly, in web 2.0 everyone has the chance to say his/her word; only, when everyone is speaking, nobody can hear. Everybody becomes Nobody. Web 2.0 is, therefore, an ideal playground for the masked man.

Is this herd-fusion occurs albeit our revolting against it, or are we engaging ourselves willingly in this process of deindividuation? I'd suspect that we are admiring the masked man. Vox Populi is Vox Dei, or is it not?

Says McLuhan: "There is a deep-seated repugnance in the human breast against understanding the processes in which we are involved. Such understanding involves far too much responsibility for our actions".

For the times they are a-changin' and who are we to ask questions?





This is the second post in the "Pressure" series (Pressure, The Man In the Web2.0 Mask and Mind the Gap)

0 Comments

Post a Comment

Sunday, October 16, 2005

Pressure

Social pressure has never been so present in technological decision making. Vendors' sales and marketing, viral marketing, blogospheres, O'Reilly radars, podcasts, open source geeks, conventions (Web 2.0 sold-out) and cocktail parties – all create levels of social pressure unseen before. I would like to bring some figures, to portray the typical prey and to try and give some advices.

The Technology Acceptance Model, introduced by Davis et Al., 1989, has shown that two beliefs are in the basis of technology acceptance: perceived usefulness and perceived ease-of-use. Of the two, perceived usefulness has been identified as the principal determinant of system utilization. Later researches found Social Pressure to be the strongest environmental variable influencing perceived usefulness.

In one phrase: Social pressure significantly affects perceived usefulness which, in its turn, significantly affects technology acceptance.

Analyze this: Social pressure sells better than a user-friendly, easy-to-use product! No wonder most of Enterprise software are so complex, and that most of the vendors' budget is invested in marketing & sales, rather than in R&D (on an average 75% [sales] vs. 25% [r&d]).

So we're under social pressure. Interestingly, though, we don't perceive this pressure as similar to the one exercised by non-IT vendors. I know many people who wouldn't buy iPOD, or read Harry Potter or wear Nike as a revolt against the herd phenomenon; I don't know many people who would scornfully dismiss ESB, EII, J2EE, SOA, "Aligning IT with Business", BPM, BAM, Ruby on Rails, O'Radars etc. We revere technological brands and logos because they signify advancement, innovation and knowledge. This makes us, in a sense, pressure-prone.

A significant pressure-source is Web 2.0, or the advent of Vox Populi/Power to the people. Blogs and podcasts, transported over RSS feeds, have become ubiquitous marketing channels. They are blitzing us with new startups, technologies, tools and products every second. Del.icio.us, Furl, Technorati, O'reilly "distributing the future" Network and the entire blogoshpere have fused into one huge technological, brain-washing, herd-ish megaphone. Social pressure under the Vox Populi paradigm is higher and louder!

But the average CIO, who takes the million dollars decisions, is not listening to the blogosphere. (S)he's got vendors meetings, conventions and cocktail parties. Two of the tales vendors are so fond of telling in such occasions are that their product is in a POC/alpha/beta at Merrill-Lynch-Morgan-Stanly and that it is actually the outcome of a detailed design work done by the vendor and some Fortune 10 companies. The vendor is therefore nothing but an emissary bringing forth the Gospel of the Fortune 10 Enterprises to the entire IT world. The conveyed message is simple: Join or Lag Behind!

That's social pressure.

I would therefore suggest that the most important role of today's Enterprise CTO/Chief Architect is "Being Hans Brinker". Like that Dutch boy, the CTO has to deeply thrust his/her finger in the Enterprise IT Hypes & Trends Dam and stop the flood.
Only, in most cases, there's no Enterprise dam.




This is the first post in the "Pressure" series (Pressure, The Man In the Web2.0 Mask and Mind the Gap)

0 Comments

Post a Comment

Friday, October 07, 2005

Smells Like Teen Spirit? (Enterprise Linux Distros)

It seems so fantastic and it smells like teen spirit: 386 Linux distributions (and growing) to pick from! The truth is, though, that in the Enterprise sphere, there's no need for DistroWatch, as the number of alternatives is aggressively squeezed into two or three. As Todd Oseth, EMC's Software VP, told me earlier this year, EMC will only support Red Hat, SuSe and Asianux, the Asian Linux. We can assume than that other software and hardware vendors will follow the same course.

This decision (to support a 3 out of 386) is highly logical from both the Vendors and the Enterprise perspectives. I'd even claim that our industry would do much better with two operating systems only (and, of course, with a similar number of hardware architectures). The reason is that the distro per-se has no intrinsic value; it is the ecosystem of the distro that counts. And the ecosystem is the outcome of the different vendors' interoperability matrices.

Before vendors can release an Enterprise-grade product, they have to run it through massive testing in a standalone, as well as interoperability modes. These tests yield the sometimes annoying but highly essential interoperability matrix, reflecting a final set of authorized variations. Each variation is static, in the sense that its constituents cannot be altered, not even on their patch level (let alone their release version).

If a vendor is to support RH, SuSe and Asianux in each of their released versions (RH 2.1, 3, 4; SuSe 8,9 etc) it practically implies a dozen or so new variations to the interoperability matrix. That's a prolonged time-to-market and naturally a lot of testing money every year! Therefore, vendors have to have a very clear business-case before a new variation is introduced. I suspect that 386 Linux distros are far from being justifiable.

In the Enterprise realm the story becomes even more complex. The Enterprise maintains its own interoperability matrix, with each variation holding much more constituents than that of any single vendor. Each component used in an Enterprise-scale deployment has to meet some pre-requisites that form the Enterprise Interoperability matrix.

Let's take a database server as a case study. Its ecosystem, i.e. the database server in its surrounding, comprises at least of the following constituents:

1. The Hardware platform
X86 64-bit Opteron or 64-bit Itanium – these two hardware architectures have completely different vendors ecosystem
2. The Operating system
Oracle 8i is supported just on RH 2.1; Oracle 9i is only supported on RH 3 etc.
3. Database Features
Some database features have their own interoperability matrix
4. The Enterprise Storage mini-eco-system
This is one of the most painstaking interoperability issues. File systems and volume managers, SAN directors and switches, Enterprise Storage Boxes and so forth. Most of the obstacles I have encountered as part of Enterprise Linux adoption have issued from this source.
5. Monitoring agents
Not all monitoring frameworks have an agent for the Linux distro of choice. Here's another aspect of the Enterprise Linux reality – sometimes, there's no choice but to introduce another infrastructure element – such as a new monitoring framework – so that the chosen Linux distro server would be monitored. While easy to solve on the tactical level (Nagios, Big Sister etc), these ad-hoc solutions have their toll on the strategic Enterprise Management level.
6. Backup agents
Backup's another major issue. Backup agents of Enterprise Backup solutions are highly selective in their Linux distros and versions. Moreover, some special backup techniques, such as those used by Storage vendors (EMC direct backup, for instance) are not supporting volumes mounted on (some flavors of) Linux servers.
7. Middlewares
Adaptors, connectors, listeners etc – yet again, these are limited to a specific Linux distro in a specific version.
8. COTS packages or bespoke Applications
Finally, the application(s) that use the database sometimes insist on a contextual certification, i.e. not just Oracle 10g, but rather Oracle 10g on Sun Solaris (and not on HP-UX, for some reason).

When all pre-requisites are in place, distro alternatives sometimes don't exist (!); if we're lucky, though, they do exist, though highly constrained.

There's no wonder than, that Jonathan Schwartz, chief operating officer and president, Sun Microsystems, has been so excited last month, when Sun new line of X86 AMD-based servers were announced: "Never in Sun's history have AMD, Microsoft, MySQL, Oracle and Red Hat stood behind a new line of products from Sun", he said. Well, that's the dark side of the interoperability matrix: sometimes, it's not only (testing) money, but also politics, competition etc. And paying close attention to Sun's announcement, it is clear which Linux distro is the one to be first supported.

Having said all that, one could wonder if Enterprise Linux worth the hassle. And the answer is evidently YES. Cost, scalability, performance and readiness for the future – all these make Enterprise Linux worthy already today. It's just that teen spirit and freedom of distro choice are somewhat irrelevant to the Enterprise Linux story.

0 Comments

Post a Comment

Sunday, October 02, 2005

Take up the gauntlet! (It's Under the Grid Lights…)

In continuation to A Hell of a (SOA) Day, there are two issues I would like to discuss:

The first is related to the WS-*: who said that SOA and web Services are interchangeable? I know of a fabulous SOA realization, linking 250 applications through 300 services with millions of invocations a day – yet nothing in this implementation is prefixed with "WS-". Given that the WS-* standards are work in progress for already so many years, there's a point in questioning if they are doing any good to the SOA cause which, as you could deduct from the case I mentioned, can do pretty well without them.

The second point I'd like to raise concerns the so many pieces of software needed to be purchased and integrated in order to implement Enterprise SOA. Why's no one taking up the gauntlet of providing a single, unified, [service-oriented!] life-cycle SOA management framework? Clearly, this is preventing SOA from being adopted on a strategic, Enterprise-grade level, as you could well see in the previous post.

So first things first: SOA is Web Services? Web Services are SOA?

Let's do a bit of semantics on Service and Architecture (as in Service Oriented Architecture). The idea behind "Service" is that APIs are no longer adequate. In the past, where applications used to run on the same room-size Big Blue, the APIs were everything - channels to the Enterprise Information heart. But nowadays, in the stateless, asynchronous and distributed Enterprise, APIs became intangible, like atoms. We need a higher-level material to build with our cross-applications, cross-companies business processes. Hence, the Service: a Darwinian artifact, evolved from the lower-level, small-sized brain (aka, business-logic) API.

Trickier is the definition of "Architecture", as it depends on the eyes of the beholder. For a programmer, the Service Architecture instructs how to build a service. The first Web Services standards - SOAP & WSDL - changed our lives for good, by enabling any programmer, who's using any language, to create shareable Services.

If you remember, the trio of SOAP and WSDL (with UDDI) riding on XML, were enough to enflame the entire industry; IBM and Microsoft released, in a haste, IDEs that could easily create or consume Services. Web Services became Celebs over night, and Microsoft & IBM couldn't but get euphoric.

There's no doubt, though, that at a certain point in time the Gorillas got sober, having the worst hangover migraine ever; for they realized what a Golem they have created. Once Services were let loose inside an Enterprise, they became overly powerful and highly uncontrollable (see 1 vs. 100891344545564193334812497256, part I (on Enterprise IT, Disorder, QoS & SLA). Services had to be managed, ASAP - but no management framework was out there.

Therefore, when SOA is discussed from the eyes of the Enterprise, Architecture bears different meaning - that of Management. Services, being mini-Enterprises, must be under constant control. Uncontrollable elements cannot be strategically deployed on an Enterprise-grade level.
Here're some random control questions, out of many others:
- Which Services are out there?
- Which depends on which?
- What infrastructures, applistructures and software components are parts of the Service?
- Which is currently available, unavailable, having a problem?
- Who's waiting for a Service completion?
- Who received an error from a Service?
- Who's allowed to invoke which Service? When? Under what context (or policy)
And so forth.

Do pay attention to a simple fact: most of these questions cannot and should not be answered on a single Service context. These questions are Enterprise concerns, and as such they should have their answers by some Enterprise controller. Enterprise SOA should be, therefore, defined as "The architecture for managing Services in an Enterprise context".

From here it is easy: in order to manage you have to have knowledge. The more knowledge you acquire, the more powerful and in control you get. Overall knowledge can be acquired only by following the entire life-cycle of a Service, i.e. from inception to retirement (ownership, requirements, design, coding, implementation, testing, deployment, execution, monitoring, self-healing, problem resolution, retirement).

Still, no company has been taking up the gauntlet of providing a single, unified, life-cycle management framework for Enterprise Services. In the meantime the WS-* committees have been working [for years] on WS standards that have no reference point (i.e. a life-cycle management framework to which they should refer); it seems that every quarter or so someone says: hey, didn't we forget something? And a new committee is launched.

I strongly believe that this state of things prevents SOA from being adopted in the Enterprise, and thus the question of why we don't have such a management framework is most pertinent.


Well, I might have some answers.
Startup: I have discussed the possibility of launching a startup on this matter with a VC named Greylock. "Boiling the ocean" was their answer. And indeed it is. So startups won't do it – it's too big for them and for their bankers.

I have discussed the life-cycle management approach with the VP R&D of a major international software company. "Oh, no", he said. "We cannot compete with IBM, Microsoft and SAP – these are the SOA execution platform vendors". I didn't have enough time to tell him that not even one of the companies mentioned has an SOA execution platform following the Enterprise requirements.

Well, if neither startups nor big ISVs can take this challenge, why don't we see such a product from IBM or Microsoft? Are they really waiting for the WS-* standards to be completed? Or did they climb up too high on the WS tree?

Actually, I think we will have such a solution soon enough; but surprisingly (or not), it will not come from the applistructures vendors but rather from the infrastructure vendors. More precisely I believe that Grid Management Frameworks will provide the missing piece of SOA management and will allow strategic, Enterprise-grade SOA deployments,. The arguments behind this statement deserve their own post, but I'll, nevertheless, mention some now:

The GRID has tasked itself with the management of virtual and distributed resources. Indeed, the very first idea was to manage infrastructure resources. Yet soon enough someone at the grid community figured out that (Web) Services are nothing but virtual, distributed resources and that therefore they can be treated as GRID components.

My second argument is that the Enterprise Grid Alliance (EGA) has well learnt the lessons of the bitter SOA failure, i.e. that managing virtual, distributed resources requires life-cycle approach. I am recommending, again, the EGA reference architecture; it could be well used as the missing reference architecture for SOA (and OASIS could well save 3-4 committees here...).

My third and last argument is based on the sayings of John Chambers, Cisco. I heard Cisco's GRID program manager speaking about Cisco's view of the world. In two words: "Intelligent Network". In a simplified nutshell, GRID, SOA and Semantic Web will be part of a Cisco's Router. And here's how John Chambers indirectly justifies this Intelligent Network vision:

“It's going too fast and (getting) too complex, and it's getting harder and harder to get our arms around it. You can't approach this problem with pinpoint products that IT professionals have to integrate”.

John Chambers, CISCO, RSA Keynote, Feb 2005

0 Comments

Post a Comment