2008/08/07

Service Oriented Argus

SOA is one of those terms i am hesitant about using. The main reason being because it is such an obvious technical style to use for certain integration initiatives. And it's so easy to fail in matters of style, especially when it is being over hyped by software vendors to an stunning degree. SOA is a strategic discipline in the area of Enterprise Architecture to gradually transform the application landscape in such a way they can be used as simple building blocks for purposes of interoperability and assembly. Being such a discipline it requires a well-balanced approach of vision, business analysis, audience, methodology and management. Just like large scale integration projects require.

Now, besides the reluctance of stating the obvious, or 'kicking in an open door' as it's called in Holland, what abhors me is the incredible self-fulfilling marketing hype around SOA especially when it comes to web services. As if using a search engine which returns results based on
popularity and sponsorship, a 'free internet encyclopedia' infested with Astroturfing, on-line applications cycling through a stage of perpetual beta, as if all this isn't enough, there seems to be a large misconception at the CxO level confusing the market-driven enterprise with the marketing-driven enterprise..

I find it mind-boggling how interwoven the hypnotizing kaleidoscope of marketing and advertising has become
in an industry where opinion was second to scientific honesty and how it has been taking over an evolutionary movement equal to the introduction and acceptance of databases. Old man Dijkstra would not have been amused.. it reminds me of a story of his where business people objected one of his computer designs because in their perception he had, kind of, been cheating because he had the freedom to choose smart people to work with.. which seems to get to the mis-conceptual core as 'user-friendliness' suffers from. Biased information is bombarded onto us in such large amounts we start believing it, we start many things anew whereas talking with a 50 or 60 year old engineer will teach you some amazing stuff from the times when computers and languages were custom-built, the same thing of which we are more than capable of nowadays but just don't see or allocate time for, because we must keep up with the flow, the endless propagation of what is now and new.

On the other hand, this widespread tendency to take credit on the future has caused a large and reasonably well-defined movement in moving away from isolated monolithic applications towards.. towards what ? Towards another uber-monolithic clutter of ill-defined web service
spaghetti ? Towards high-performing lego-style applications with well-defined interfaces for business functions ? Considering economical path dependence and the evolutionary aspect of acceptance of technological innovations, the large majority of initiatives will end up with spaghetti, spaghettini and spaghettoni, which may be more than fine for the issues addressed, but please don't call it SOA. Select a project that is challenging and worthwhile from both business and technology and just start applying SOA as a discipline. Use email, message queues, web services, ftp stations, database level ETL, paperware, whatever, just build an integrated solution and do it architecturally elegant.
Wittgenstein, that nice and logical buddhist from
Austria, had this nice dictum, 'Whereof one cannot speak, thereof one must be silent'. Don't talk about SOA, just do it.

4 comments:

Eric said...

Yeah, I agree. SOA is a nice pattern for automating business processes using well defined services. However, it should be obvious that it does not apply as well to all business scenarios for example mass-data moving & handling or asynchronous messaging. This is why real world architects focus on the concrete benefits and applications. They "just do it". On the other hand, "architecture astronauts" are forcing solutions into problems that don't exist. They can only "talk about it".

I especially like the following links:

SOA Without ESB

Architecture Astronauts

Regards
Eric

kukan said...

Hey Eric,

Thanks for the heads-up. Well, i actually think SOA can be applied to file servers, email, message queues, etcetera, but it's not the silver bullet as presented. Nor is agile computing which is so eloquently presented in the Thoughtworks presentation, nor their web 2.0 twist they present at the end. Yes, they are right within their particular context, but also the SOA vision is right. It just takes a relatively long and large-scale project, steady vision and a pragmatic approach.

The Agile Manifesto is wonderful, but i have seen it suffer from the same problems as SOA does, the whole thing gets picked up and shortcuts are being applied because it needs to find a balance between the promise and the organization. So, we get Agile without close cooperation, we get Agile without co-location, we get Agile with junior developers, we get Agile mixed with off-shoring and outsourcing and little chunks of old style linear program management without addressing the scaling issues, communication problems and prioritization..
Agile is great, but the change is too much for what most companies are capable of, just like SOA.

Now, if only there were a minor evolutionary mutation in the toolsets that allow for rapid delivery cycles, that would make so much of a difference. And i don't see that particularly addressed with the funky class-loading and dependency injection possibilities in Spring, not just yet. What i would like to see are dynamic languages, and even more so dynamic Java. That might not be defying causality, but would at least enable a more simple introduction of e.g. a new version of a message definition. But how to do impact analysis for such in a largely distributed environment.. How about a registry ? Oh well, feet back on the ground and let's just make things happen.

Take care
Paul

mkj6 said...

SOA addresses real problems but it is nothing really new. The SOA acronym has been mostly invented by software vendors and analysts trying to recover from the new economy bubble, in search of the new big things to sell after application servers becoming a commodity.

Service-Orientation is about building a domain model and designing good business-oriented interfaces. It means that IT people should stop masturbating with technologies and start listening to real business needs, something which is actually made hard by the fact that still too many customers have IT departments trying to buy buzzwords instead of solutions. Unfortunately this has transformed a very important concept like SOA into something polluted.

Imagine a company where the ones in charge of buying cars never had a driving license: this is the present SOA market. I have been with a potential customer last year, the IT manager in charge of buying EAI solutions told me they already implemented a SOA but they weren't happy: everything before was decoupled and usable off-line, now everything is synchronous and if a single activity fails the entire business process fails. Basically they just understood that SOA means: put synchronous web-services everywhere... There are no acronyms against human stupidity.

Ciao

kukan said...

The circus around SOA reminds me of the gold rush in the 2nd part of the 19th century. The people that got rich of gold were the ones selling the mining tools..

But yeah, what is so painfully apparent with SOA is that something of quite large value is being warped, misrepresented and wrongly implemented on a large scale. The customer you mention is just one of many sad examples.. and quite the reverse of one of the earliest large scale EAI implementations i was involved with. At that time, that customer wanted to do a 150 million euro SAP implementation, but their IT landscape provided already some 97% of the functionality required. Moving to SAP would actually reduce that value. So i constructed all kinds of scenario's where a strategic use of EAI (and indeed applying SOA) would meet their requirements at about 25% of the price, although they'd actually pay a subscription fee on functionality x usage. The ideal for them was that it allowed for phased transitions from one system to another without much fuzz, a rough version of plug & play.
Now, about 8 years later they are heavily using EAI, very strategic and purposeful, hooking up with their close clients and vendors. And now, at this stage, now that they have pipelines for their normal business, are they beginning to think of web services and composite applications and the likes..
It can be done.. but imo technological evolution creeps up abstraction levels along the OSI model at a relative slow pace, there is little value in shouting around things like SOA, Space-based computing, Cloud-computing etcetera, whereas it is mostly clear that these things are becoming capable because the underlying network allows for it. And these are the gradual shifts that add value to e.g. virtualization techniques, which have been around for quite some time already, but now 'suddenly' bubble upwards because something scarce is becoming a commodity.
The problems arise when things get all surface without any depth, just like Y2K, and as shit floats up...

Hey, how about that Higgs boson at the LHC in Geneva, huh ? Still a month to go, but who would have every thought space is a holographic superfluid.. Ain't that something ?
"We are such stuff as dreams are made on; and our little life is rounded with a sleep."
:-)