Tuesday, November 29, 2005

Microsoft's Linux Strategy (Trojan Penguins, Part II)

My sequel to SOA, Matrix is still under construction, so in the meantime - a kind of a childish "told-you-so" post that I couldn't resist :). Here it is.

Last week IDC published its Worldwide Quarterly Server Tracker report, presenting current Server sales figures and market segment analysis.

Will you be surprised to learn, that for the first time (in history) Windows is the Sales Leader across all Servers' segments? (High, Mid, Volume)

"Microsoft Windows servers continued to show strong growth, as revenues grew 17.7% and unit shipments grew 15.3% year over year. Significantly, quarterly factory revenue of $4.6 billion for Windows servers represented the largest single segment of the server market for the first time – increasing revenue share by 3.0% over 3Q04 – as customers deploy more fully configured Windows servers in support of scalable workloads and consolidation projects".
Source: IDC's Worldwide Quarterly Server Tracker, November 2005

Think about it for a moment: how come Windows is enjoying a consistent, quarterly growth in revenues and market share? Has Microsoft released any new and revolutionary Server Technology in the last copule of years that we've missed? If not, what than is pushing Windows Server forward?

I am referring my dear readers to a post I published a couple of months ago - Penguins at the G.A.T.E.S of Troy, where I explained how Microsoft is going to win big time because of...
Linux.


.

0 Comments

Post a Comment

Friday, November 25, 2005

SOA, Matrix

I have decided to explicitly (try and) explain why SOA is a fundamental paradigm shift that will change our lives. I'll start by briefly tracking the current whereabouts of the SOA meme, just to take the discussion far away from Integration and Interoperability.

Last month, OASIS published its early seeds of an SOA reference architecture. In the introduction, Steve Jones from Capgemini, gave his warning on SOA: "Services have been hijacked by technology vendors trying to sell integration and development tools, which most normally focus on “Business Process”, “Orchestration” or “Web Services”. This technology driven approach fundamentally misses the point of Services".

And Dave Linthicum published last week a warning on a hijacker named ESB: "A mere messaging system, with Web services interfaces, that has been renamed ESB. Just like all middleware became EAI back in 1997/1998, and later the same and unchanged middleware became B2B when that word became hot. Get the pattern? The technology remained the same, but the TLA change to slot into an emerging market. You got to love the reuse aspect of that".

So industry experts are warning us from keeping on falling into the technology trap, promoted by the Vendors. But the meme energy of SOA is currently centered on Integration, Interoperability and Agility. Wouldn't it be natural to translate these ideas into ESB, Web Services, BP4WS engines and so forth? I think it is natural. And I think many people are feeling, just because it’s so intuitive, a cognitive dissonance in trying to figure out where’s the drama.
YET I am sure that whoever practiced SOA in a strategic, Enterprise level, felt that there’s much more to SOA than solving Integration problems & facilitating Interoperability. SOA is a paradigm shift and it is about to change our lives. I don’t remember, though, any messaging bus that made me feel this way (though I did get excited at the time from TCP/IP sockets :)). I would therefore suggest a different perspective on SOA and hopefully succeed in communicating the essence of the revolution.

SOA is the foundation for the ultimate Management & Control System. It solves the biggest problem of managing and controlling an infinite number of distributed and heterogeneous objects that nevertheless make part of a single entity – be it the Enterprise, the Internet or whatever.

Management Silos of today's Enterprises are characterized by two dimensions: the Class and the Life-Cycle. By Class I refer to any Class of objects found in an enterprise: processes, employees, applications, routers, storage units, servers, databases, stored procedures, UI, codelets, scripts and so forth. By Life-Cycle I refer to the stage in which the object is: development, testing, execution, operation, support. By Silos I mean that most of the management tools out there are usually managing one Class in one stage of its Life-Cycle.
This state of things, where information is locked behind hundreds of silos, prevents end-to-end management. “Knowing that a certain counter has reached 1000 is interesting, but does not describe the dependencies of one service in another, or provide the ability to assure redundancy when a network link is lost” (The Continuing Evolution of Distributed Systems Management), to give one example.

Along history, people have always aspired at the creation of a holistic, unified, semantically-common world. The reversing of Babel, the creation of Utopia. Accordingly, the Distributed Management Task Force (DMTF) believes that if all management systems will adhere to its Common Information Model (CIM) management problems would be gone. Tim Berners-Lee and the Semantic Web/Ontology fraction think the same about the Internet. Well, I would dare say that just as the tag-o-mania proved the semantic web is utopic, CIM is deemed to have a similar destiny. Diversity, heterogeneity and disorder are much more powerful than standard, homogeneity and order. So changing the multi-dimensional, physical world into an opaque reality is not something I believe to be possible.

We could, nevertheless, do it in our own virtual reality. Oh yes: in my virtual world everybody speaks the same, looks the same, adheres to the same social rules and reports periodically about anything I need to know – so I could rule. Oh yes, Knowledge is Power and in my opaque virtual world, I have an absolute knowledge, therefore I have an absolute control.

The missing link: SOA allows the creation of a virtual, unified, homogenous, uni-dimensional world on top of a fragmented, distributed, disconnected and heterogeneous world, without having to change anything in the real physical world. SOA achieves this by employing a brutal reductionism: it reduces all Classes to a unified level of Resources and all Methods to a unified level of Services. That's it, and that's what gets managed: Services & Resources. SOA is a dimensions compressor: humans, processes, infrastructures or applications are collapsed into resources that provide services. Managing meta-data, policies, inter-relations and dependencies with such a simple and opaque representation is easy. "For the next decade, most of the value in SOA will be captured by making everything dumber instead of making everything smarter", says Miko Matsumura from Infravio (probably in a much different context, still it fits good to my thesis :)).

But actually, SOA is more radical than that: it settles with the management of Services only. As if the Resources do not matter, unless they converse. As such, SOA manifests itself as a linguistic phenomenon. As we know, Language is Reality, and Communication is Existence (unlike what Descartes thought). Hence, Resources are of an interest only when they communicate. According to the linguistic theory of Pragmatics, any communication is a utilitarian speech act, or – under the SOA paradigm – a Service. Therefore, in order to manage reality it suffices to be in a complete control of the speech acts, or the Services. Words are placeholders for acts (Austin, J.L., "How to do things with words"), Resources are placeholders for Services.

Differently put: it is enough to control the communication lines in order to control reality. Service-Oreinted [Management] Architecture provides the ultimate Management & Control System by focusing on mansifested actions only.

In my next post* I [ might | will ] discuss Cisco's Intelligent Information Network vision and Google's Web 2.0 Services ("I'm a Google Person") – two great [and rare] examples of companies which understand SOA to its management & control bones.

* There are two sequels to this post: In SOA We Trust, that further elaborates on the ideas here presented and discusses Cisco AON's role in the Enterprise, and Organizing the Information of the World, which explains why Google's the Real-World SOA.

3 Comments

By Blogger davids, at 2:13 PM  

You are facing a daunting task of bridging between the Architecture and the Implementation. It's the philosophical equivalent of reducing metaphysics to the ontology of the actual being. Architecture is truly a metaphysical environment limited only by the capabilities of the human brain, and therefore virtually limitless in creativity and intellectual wizardry. The reality (phusis) is much more difficult to tackle and therefore the challenge of bridging between the Architecture and Implementation. He who can achieve this by creating (defining) the fundamental bridges (real world components) between the two concepts will be remembered as the Aristotle of SOA.

By Blogger Philip Hartman, at 6:42 PM  

I read recently (I think it was in CIO) that basically recommended that CIO's stop spending so much time looking for new ideas and spend more time trying to overcome resistance to change in their organizations... if an idea isn't implemented it is basically worthless.

By Anonymous Ittay Dror, at 8:20 PM  

i think SOA to the enterprize world is like what OOP was to the programming world: in C you have an exposed set of data (C struct) floating around your system, unprotected, where anyone could do with it what he liked, without any control. in an OO language, the data is hidden, and only methods are exposed. your data is then safe (well, safer, depending on the methods you write)

Post a Comment

Sunday, November 13, 2005

SOA Dialogues

I had some interesting meetings recently with both Enterprise Customers and Enterprise Software Vendors around the subject of Enterprise Integration and Web Services. Known for my Telco-Grade SOA implementations, I've been invited as the SOA incumbent. What has happened in these meetings resembled a shock therapy. Well, the therapeutic effects are yet to be proven; but judging by the number of dropping jaws – a shock it was.

Here's an excerpt from the vendor's meeting. A picture's worth a thousand words.

Q: Well, being an SOA expert, I'd like to start by asking what WS-standards you were using?
A: No one...
[5 seconds of deep silence].
None.
Q (and the rest of the attendees looking at me in disbelief, as if a horrible consulting swindle has just being revealed): You didn't use any WS standard?
A: No. I don't think SOA and WS-* are interchangeable. They are related, undoubtedly, but they are absolutely not interchangeable. I am here to tell you how to implement SOA. WS-* will come further down the road, if at all.
Q (trying a different tactic): So what's a Service?
A: Service is the façade of anything
Q (visibly annoyed): If it's the façade of anything then it is the façade of nothing!
A: A Service can mask anything that provides functionality. It can mask a granular API, or a business process spanning across multiple applications and enterprises. It can even mask a grid layer providing a computing resource like CPU. So practically, a Service can mask anything.

And then the conversation went on for nearly two hours, in which the internals of Enterprise SOA management were thoroughly discussed. I felt, though, that all the participants in the room were in a great puzzlement, not knowing how to buy this unusual SOA expert.

The meeting with the Enterprise Customer was just as tensed. I was actually invited to comment or verify the work of another consulting firm that prepared a thick-doc recommendation about the future Enterprise Integration infrastructure. And, the manager of the consulting firm said: "Obviously, the Integration architecture must be open and by open I mean complying to nowadays' standards of WS-*, such as WSDL, SOAP, UDDI, WS-Attachment and more."

WS-Attachment? I felt my own jaw dropping. I looked at him in disbelief, thinking: "Your audience is a group of IBM veterans that still live inside the Mainframe. Their kick is CICS. What are you trying to achieve with this WS-Attachment thing?" And then, "Reflexes got the better of me, and what is to be must be…I shot the Sheriff".

Waking-up from this sudden day-dream I found myself in the midst of a tumult. The IBM veterans were on the verge of becoming completely depressed by the idea of having to Web Servicize their entire applications portfolio. And the manger of the other consulting firm was reassuring them by saying that even "Shai Agassi, the golden boy", is on his side – and he fumbled through his presentation until he found a slide of SAP's Enterprise Services Architecture. I sneaked out unnoticed, put on my super hero robe and reentered the room as the SOA-man. "I am the SOA-Man" I shouted to the cheers of the old IBMers.

Ok. Let's cut it here.

What I'd really want to do is to make my SOA point clearer, as I do acknowledge it is bizarre to talk about implementing SOA without using WS-*.

So using my architecture reverse-engineering techniques I would first claim that there are only two application integration architectures: point-to-point (direct) or Hub and Spoke (the go-between). P2P is an ad-hoc, unmanaged, decentralized integration architecture, in which applications are directly connected one to another. Enterprise-level P2P is like Enterprise-level Anarchy. Actually, we cannot seriously claim P2P to be "Architecture", if we consider architecture to be a deliberate cognitive artifact. P2P is indeed the lack of architecture. And I am witnessing, too often, P2P integrations migrated into P2P Web Service integrations by people who believe that now they have finally architected their integrations.

In the Hub & Spoke architecture, all inter-applications communication is bridged and managed by the Hub. When Big Brother is in charge, great Enterprise-level things can happen, easily. This leaves a lot of place for as creative and robust architecture as possible. The Hub can authorize and log; translate and route; handle exceptions and notify errors; briefly – the Hub is the Services Framework. As a framework the Hub masks: it masks technology, semantics, failures, downtime of providers and so forth.

That's for architecture; now for the implementation.

I think the implementation doesn't matter. The Hub can be built using any programming language, using any persistence mechanism and bridging any two technologies. Web Services, in this sense, are nothing but an invocation standard. The Hub is capable of invoking a COM object, an ejb, an Oracle Stored Procedure or… a Web Service. One can request a Service from the Hub by placing the request inside a SOAP message and sending it to the Hub over http, or by placing a proprietary, non-soap request inside an http post, or inside a database table: that's the idea of masking – every application thinks "I am the world" – and the Hub allows it to feel so. And that's today biggest challenge: centrally managing and integrating a bunch of heterogenous, distributed applications, while giving each the illusion it is the "one". It's just like the Mainframe used to be, only it was indeed one physical and logical thing - so it was not that much of a challenge...

Having said all the above, it is clear that current applications shouldn't go through any changes to be centrally integrated – the Hub will take care of what's needed.

Should the Hub be constructed around WS-*? Well, so far I couldn't see the business value of WS-* inside the Enterprise. Moreover, so far WS-* haven't been fully standardized, nor there has been one coherent reference architecture for WS-* that the industry can rely upon. But I am willing to change my mind. And when that happens, I'll let you know.

4 Comments

By Anonymous Muhammad Zahalqa, at 2:26 PM  

It's seems that most of the buzz around SOA is driven by misunderstanding of the real meaning of SOA.

Architecture is almost like diamonds (for ever), implementation is always constrained by the available or lack of technology and standards.

By Blogger Muli Koppel, at 10:23 AM  

Hence, an "Open Architecture" is one that is indifferent to any standard or technology. I think that's openess and not WS or J2EE or whatever you'd pick from the bunch of current, temporal, standads.

Thanks Muhammad for your comment

Muli

By Blogger Joshua Fox, at 5:35 PM  

Your comments are quite correct.

Just to add a point in favor of where WS-* can provide value: Your proposed architecture requires the hub to provide adapters into many technologies such as Java, .NET, mainframes, etc. Adaptation must include the functionalities of invocation, discovery, transactions, etc.

Not too hard to do, but you'd save yourself this step if you could easily procure adapters to convert any of these technologies, and other, more obscure ones, into your hub.

By Blogger Philip Hartman, at 5:18 AM  

It seems that the only thing which makes the current buzz around SOA perhaps a little different from previous silver bullet discussions like CORBA, message oriented middleware, etc. is that in the case of SOA enabled by web services, both the Microsoft camp and the non-Microsoft camp (IBM, Sun, HP, BEA, etc.) are finallly agreeing to at least some of the same standards. Without this agreement, SOA is just the latest hub and spoke marketing fad.

Post a Comment

Thursday, November 03, 2005

Mind The Gap

It's time to conclude the (unplanned) saga about social pressure and technological decision making (Pressure and The man in the Web 2.0 Mask). As you might have noticed this pressure farewell-post took me a while to accomplish. The reason is that the issues raised are far from being limited to technology decision-making: they touch the basic conflict & tension between the Individual and his/her reference Group; they touch the commercial powers driving noble ideas and their conscious or unconscious will to enslave the end-users; and so forth. So a bit self-depressed, I've started looking for support groups around the net… and stumbled upon some interesting voices.

I'll start with Dan Farber, a Gillmor Gang member, who shared with the Gang listeners his impressions from the web-2.0, 2800 US$, sold-out conference:

"These (Yahoo, Google, AOL) are companies who'd wanted hundred of millions of people to be their users… [they] keep building things, making things that are sticky and where YOU basically brand yourself: 'I am a Google person', or 'I am a Yahoo Person', an 'AOL Person', or a 'Microsoft Person' and that's really how it's shaping up".

I also came across Nicholas "Does IT Matter?" Carr's post The amorality of Web 2.0, which reminded me of Hans Christian Andersen's The Emperor's New Suit and the child exclaiming “But he has nothing on at all”. With arguments that turn mostly around Wikipedia, he demonstrates how shallow, inaccurate and disturbing the Vox Populi might be.

Lastly, I re-read an article I was reading some 3 months ago titled The Economics of Commercial Open Source. At the time I was surprised to see the word "Commercial" prefixing its antipode - the supposedly commercial-free "Open Source". So I came back to this article, written by Lajos Moczar, and found that he had written another brilliant analysis titled The Open Source Monopoly. Here's an excerpt:

"We now are constantly engaged in what is actually an abstract exercise in determining "the best". It is a seductive argument - after all, don't we want the best possible database, car or mortgage rate? It is more enticing because we believe that we are being "objective" and therefore highly evolved. In fact, however, we have traded the reality of our own subjective needs for somebody else's subjectivity disguised as objectivity! There is no objectivity when anyone can present a product as "the best". If you don't know your own needs any more, how can you possibly distinguish? The only way is through some artificial means like popularity or price".

This last piece is the best. It raises the problem in all its ample so now a solution could well be sought.

My solution has always been Architecture: this abstract, immaterial way of thinking about needs, concerns, pressure and identity. Architecture is stronger than Technology, and it gives me a sense of control I lack in the Panta Rey technological-river. Yesterday, Python "rocked", and the day before that – Perl, but today – we could all well tell - the king no doubt is Ruby on Rails. Today I'm a Google person but for a web 2.0 bread and pottage of lentiles, I would love to become a Yahoo's. Net dynamics, or is it not?
So Technology is ephemeral, trendy, and popular. Let's say it a la Shirky: Technology is overrated. Architecture, on the other hand, is underrated, even though it is presumably more resistible to time, and it is driven not by the principles of Economy and Venture Capitalists but rather by the principles of the Seven Artes Liberales: (1) Grammar (2) Rhetoric (3) Logic (4) Arithmetic (5) Geometry (6) Music Harmonics, or Tuning Theory [Number in time], (7) Astronomy or Cosmology.
I would even claim that Technology restricts and limits the work of the architect. If architecture is reversed-engineered from an existing portfolio of technologies, paradigm shifts wouldn't be possible. Pay attention to the difference I'm making here: technology advancement will occur; paradigm shifts won't.

So what I usually do while digesting new technologies, is to reverse-engineer their architecture. And if my existing architecture is equal or better – I am not engaging myself in any technological change whatsoever. But, if the pure principles behind the new technology are better than those I employ, well – that's usually an exciting moment.

To sum it all up: there's a gap between your needs and the technologies that vendors and web 2.0 gangs are offering you. Mind that gap and make architecture your point of reference - it will help you float.







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

2 Comments

By Blogger Philip Hartman, at 3:00 AM  

I really liked your insight about reverse engineering a vendor architecture and comparing it to what you already have.. and how paradigm shifts don't come from basing an architecture on the products in place. I put you on my blogroll.

By Blogger Muli Koppel, at 11:55 AM  

Hi Philip,

Thanks to that! See u around

Muli

Post a Comment