all bits considered data to information to knowledge


Putting “E” in ESB

Forrester's survey data shows that service-oriented architecture (SOA) still has strong penetration and high satisfaction rates. Even though today's headlines focus more on cloud computing, mobile applications, and social networking, enterprise interest in SOA-related products remains significant. However, among the four major SOA specialty products, enterprise interest has shifted away from enterprise service bus (ESB) products.

Here's a shocker - Enterprise Architecture is hard.

I believe the following are the reasons behind "interest in ESB shift" among the enterprises.

ESB is the heart of SOA, and not many enterprises are willing to undergo "heart surgery" without compelling reasons to do so. For better of for worse, ESB is a "big bang" concept - unless the entire IT eco-system is re-arranged around this fundamental concept there will be no sizable benefits to realize; given a chance, enterprise always will opt for incremental change.

ESB takes concept of software re-use to its logical conclusion, and requires shift in thinking on how software is designed, constructed and integrated. The re-use promise of object oriented paradigm got a lot of attention but ultimately failed to deliver, mostly for reasons that had nothing to do with software engineering.

ESB is hard. No matter how many "SOA for dummies" books are published, the actual implementation is either technologically challenging or expensive, or both. Explaining its benefits to CFO is like explaining theory behind acetaminophen's physiological effects to a five-years old with high fever, except that you do not report to a five-years old.

So, what's the prognosis? The idea of ESB is here to stay; the concept of universal communication channel, its orchestration capabilities, its promise of services reuse make perfect business sense. The actual packaging will have to change ... not unlike bubble-gum flavoring in bitter medicine one has to swallow for his own good.


Dark waters and thick clouds of the skies…*

Will cloud change the ways we architect software?

Despite all the hype, cloud computing is little more than ability to procure computing capacity on demand, platform as a service; it is virtualization on steroids...
It holds the same promise as Internet had in the beginning  - levelling of the playing field. Instead of buying expensive hardware and software one could configure a whole farm of servers within an hour, pay only for what it is being use, and shut down when no longer needed: no unused licenses, no hardware to auction. Ultimate flexibility.

This also would give rise to unique architectural solutions..Imagine, that your system decides that it needs to increase computing or storage capacity to meet an increasing demand. In physical world this would mean buying and configuring a server, plugging it into network, installing all the software - and this would  involve someone doing the actual work... In the cloud all of this can be done automatically through API.
A software system that grows, shrinks and configures itself... This what I call paradigm shift!

SOA yields itself very nicely to the cloud, one might say this is a marriage made in heaven; ultimate in distributed computing, a first class cloud citizen. Imagine a self assembling software where kernel system discovers services, and strings them together into useful processes according to some vaguely spec'd needs... I can dream, can't I?

*He made darkness his secret place; his pavilion round about him were dark waters and thick clouds of the skies. Psalm 18:11


Software Development Trends

Once in awhile I stumble across an article that raises questions I am chewing upon myself. Here is one, The Decade of Development  by Darryl K. Taft.

He proposes a Top 10 list of trends that had impacted Software Development in the past decade. And, of course, I had something to say about each of his points 🙂

1. Web Services/SOA

Yes, most definitely. This is logical evolution of distributed computing. And it is past its potty-training stage as well. Combined with platform as a service it would virtually (pun intended :)) guarantee interesting future.

2. Rise of Open Source Software

Yes... No.. Maybe.  Definitely not to the same extent as other trends listed

3. Web becomes #1 development platform

A bit redundant after Web Services/SOA , and hardly a major trend unto itself. Distributing computing, WOA (Web Oriented Architecture) would be more relevant.

4. The Emergence of Web Frameworks

Most emphatically - YES. Once we stop re-inventing the wheel things will began to improve. Take a hint from electronics: hardware engineers do not start designing ASIC from sifting sand, and yet their creativity still has room to flourish (most often heard complaint from framework-phobic developers). Component based approach and frameworks will lift software engineering from craftsmanship into industry. It goes down to a nitty-gritty technical detail such as unit testing and logging and all the way up to Application Life Cycle Management frameworks in context of Enterprise Architecture

5. Web 2.0

I believe that this is a hopelessly over-hyped buzzword. Yes, there are new tools for collaboration, but the idea is hardly new. Groupthink blown to epic proportions.

6. Simple Beats Complex

Any time, I mus add! Hardly a decade-long trend. I would argue that this goes back as far as human history (though not necessarily in straight line): arcane system of tribal lore and taboos gets replaced by a codified law system (though some might argue that it is no less arcane...) Also, one must beware of oversimplification. Albert Einstein once famously remarked: "As simple as possible but no simpler"

7. The Rise of Scripting/Dynamic Languages

I have to admit, this caught me completely off-guard at the beginning of the century. I used to regard these dynamic languages as second class citizens, even having witnessed power of the Shell (KORN, C, bash). I suspect that the major factor is increased hardware power which alleviated inherently slow performance of scripting languages. Another pet peeve of mine was that scripting languages used to be weakly typed; this either changed (Ruby), or was adressed through a variety of frameworks...[interesting discussion on (de)merits of weakly vs. strongly typed languages here) In retrospect it appears logical (de)evolution: compiled -> byte code -> script... I predict that pendulum will swing back, and we'll see resurgence of compiled languages, maybe self-compiled, JIT compiled etc. Just take a look at emerging EXI -  binary XML standard - one of the oft-touted features of XML was that it is "human readable"; apparently this ceased to be of paramount importance

8. The Developer Community Bifurcates

I disagree, I do not see it as a trend, but rather as a human trait. Once the entry barrier into the field was lowered (thanks a lot, Visual Basic!), the field was swamped with accidental programmers. Even before that, there were sloppy written COBOL and Algol code and atrocious pointer math (just look out there how many tools are created to detect memory leaks in C code)

9. Heterogeneity Rules

Yes, this is an unexpected twist on the old "best-of-breed" adage, and facilitated by inherently heterogeneous web. XML, Web Services and scripting languages complete the picture.

10. The Emergence of Team Development (and the rise of Agile development)

This is a biggie. Finally, we are at the dawn of engineering, with (emerging) body of knowledge and methods to tackle notoriously hard-to-pin-down software problems. Methodology and frameworks (yes, I do see Software Factories on the horizon!)

I would also add raise of Architecture, especially Enterprise Architecture; understanding of the ultimate importance of ecosystem in this inteconnected age.


Who’s got Web Services right

Once in a while, Microsoft does the right thing, and the rest of the programming community ought to simply acknowledge the contribution, and move forward. Consider web services: creating a webservice in .Net is [almost] as easy as marking a function with WebMethod attribute .

Here're some well taken points emanating from Mark D. Hansen - a bona fide Java developer and architect (and the author of SOA Using Java Web Services book)

"Adding web services to Java applications should not require programming. There should be a simple ON/OFF switch. You should be able to select some business logic, flip the ON switch, and publish it as a web service.  Unfortunately, Java isn’t designed that way. Java requires you to write code, annotate classes, recompile, and redeploy. And it isn’t simple coding either[md]particularly when you run into problems with Java/XML serialization."

Mark goes on quoting in his book the blog of Dave Podnar - a hilarious summation of the problem!

Dave Podnar's Five Stages of Dealing with Web Services

1. Denial: It's Simple Object Access Protocol, right?
2. Over-Involvement: OK, I'll read the SOAP, WSDL, WS-I BP, JAX-WS, SAAJ, JAXB, … specs. Next, I'll check the wiki and finally follow an example showing service and client sides.
3. Anger: I can't believe those
#$%&*@s made it so difficult!

I could not find the remaining two stages on the Net, but would speculate that they either deal with either reaching nirvana or switching to COBOL programming...


SOA is dead, long live SOA!

A couple years ago I came across Joe McKendrick's article The Rise of the JBOWS Architecture. It was smack in the middle of the big SOA (Service Oriented Architecture) hype cycle, and right on target. Lots have changed since: SOA was buried (notably, in Gartner’s report on the subject and Burton’s group Anne Thomas Manes article), dug up (for instance, the very same Joe McKendrick ) , and resurrected (You’ll all be doing SOA in 18 months )  Strangely enough, all these events appear to happen in no particular order…

For me, SOA was not a new concept; it was yet another incarnation of distributed computing. Anyone who had struggled with DCOM and CORBA would appreciate elegancy of XML based communications over HTTP. So, there is no doubt in my mind that SOA is here to stay; it will bounce back, and will become the next real thing, albeit scarred and hardened by tech vendors attempts to make a quick buck.

Back to JBOWS architecture. I found myself explaining – times and again – to the managers on every level why web services do not equal SOA, and I came up with a metaphor that appears to be working for lots of folks: mail delivery system.

If you need to deliver a package from point A to point B, a courier service would be one option. It is fast, it is reasonably secure and it is reliable; you can even trace the way the parcel will be delivered to the recipient, All you need to know is the exact location (address) of the point B. Oh, and you need to pay the courier.

The second option would be USPS – United States Postal Services. It is a lot cheaper than private courier; it is reasonably fast, reasonably secure and reliable. It also could forward your mail should your intended recipient have moved without notifying you beforehand.

This is in nutshell the difference between JBOWS and SOA. The latter is all about economies of scale, creating infrastructure with built-in fault tolerance (what if your courier company had run out of couriers just when you need to send a package) and ability to orchestrate the deliveries according to some business rule. The former is brittle, non-scalable and has very low fault tolerance barrier;  and it is also by order of magnitude more expensive in the long run (admittedly, SOA requires more up-front costs).