mobrec

So
A puzzling new meme regarding Vendor Driven Architecture (VDA) has popped up in around SOA. The thought behind this seems to run something like this: companies should buy 'best of breed' (BoB) solutions for their SOA and not buy a particular vendors suite. Vendor suites are further demonized by calling them “comfort technologies”.

Wow. Didn't we hear all of this 'best of breed' versus software suite drum banging about ten years or so ago in IT? Then the play wasn't SOA but EAI. So, yes, by all means go buy whatever you think is 'best of breed', then spend years trying to integrate it all into something that might meet your shifting/evolving business requirements over the integration life cycle. I can't think of too many companies (if any) that would advocate the BoB approach again.

Another dimension to this decision that seems to get lost is that there is value to the Enterprise by constraining technology choices — this is part of what Enterprise Architecture does (or should do). If every project is free to pick their own 'best of breed' the corporation will quickly wind up with an unmanageable mess of disjointed products (and integrations, etc). Many of us in large corporations have seen this one play out as well. Enterprise standards are a necessary 'evil'.

Further, it is entirely possible, valid and valuable to compare business requirements to the vendors/products that the Enterprise has already decided on as standards. It would be rare that there wasn't a 70% or better 'fit' with any contemporary enterprise application portfolio. My point is, the decision to choose a vendor product doesn't have to be 'just because'; it can be because an existing vendor can solve the problem without having to introduce another technology/vendor. Stated differently, vendor selection doesn't by necessity have to start outside of the existing enterprise standards.

Let's say that the analysis is performed and finds that a BoB vendor has a few more bells and whistles than one of the approved vendors. In my mind, the next step is not to jump to the BoB vendor, but to perform a further analysis around when (realistically) the enterprise would be ready to take advantage of the differentiating feature(s). If the answer is 2-3 years, then there is a good chance that the “comfort vendor” technology will have caught up to the niche vendor. This is one of the tricky things around requirements analysis that often gets overlooked — much of the functionality will not be consumed out of the box, but only after there has been a significant amount of analysis, design and implementation. The industry and products keep evolving, just as the requirements do. Here it is valuable to have a vendor who has an articulated technology roadmap that will guide the follow-on analysis.

So, to me, it seems VDA is a symptom, It is a bad thing only if you blindly follow whatever your vendor is telling you. But at that point, you certainly aren't doing architecture nor are you doing due diligence on your requirements gathering and analysis. That would appear to be the bigger problem and is much more likely to have far more damaging consequences that 'catching' VDA.

Technorati Tags: architecture, soa, vda, enterprisearchitecture

So
In the spirit of the segment that Bill Maher does on his HBO show, here are a few of my New Rules for SOA:

1) Stop telling me that 'there is nothing new about SOA'. Everyone knows. No, really, they do. The fact that services can finally be implemented in a shared, non-prorprietary manner is what is new. And while it shares some conceptual similarities it is not 'just like CORBA'. There is nothing about this observation that adds anything to a discussion of SOA.

2) Stop calling it SO-UH. My experience so far has been that anyone who says 'SO-UH' instead of S.O.A has a better than 90% chance of not knowing what they are talking about. And then they go on to prove it over and over by saying clever things like 'SO-UH Architecture', 'SO-UH Services' and 'SO-UH Orientation'.

3) Stop using the tired old expression 'boiling the ocean' when referring to SOA projects. I may be overly optimistic in thinking that businesses have learned quite a bit about implementing large projects over the last 30 years and recognize that a phased approach is almost always the best way to go. This is an interesting one because while most true practitioners advocate a quick, iterative approach, several of the big consulting outfits have talked about 'not thinking big enough' for SOA and advocating huge, overly complicated rollouts. And, as previously discussed, the agile 'failing to plan' dream doesn't work.

4) Stop saying that SOA isn't a 'product'. I am not sure who doesn't get this. The architecture part of the acronym should give that away. There are any number of vendors who what to sell you their SOA-enabling products, but none of them has an SOA for sale. Similarly, there are also companies that will sell you an Accounting or ERP system. The purchase of the product does not instantly give you balanced books or a bill of materials. The business must take the building blocks they purchased and make them work in support of the business (which is rarely exclusively a technology exercise). SOA is no different.

5) SOA is not EA. SOA is one tool/approach in helping to achieve some of the technical goals of Enterprise Architecture — it is not a substitute for EA. I would be willing to say that without a well functioning EA discipline, any SOA effort will wind up not providing true enterprise services and value. Instead it will yield pockets of unmanaged services that may or may not interoperate based on which project developed them.

Technorati Tags: soa, enterprisearchitecture, newrules

So
With the typical firm grasp of the obvious, the following quote appears at the top of a posting entitled “When all else fails, try SOA best practices“:

“We're seeing a lot of people out there struggling with SOA, trying to do SOA,” said Ronald Schmelzer, senior analyst with ZapThink. “They are worrying about building services and running services. They are having to ask themselves questions. 'Why am I doing this? What services do I really need to be building?' They need methodology.”

Well and it's no wonder given the various forums that SOA has on the Internet. The problem is, everyone has their own methodology with about 80% of it being identical to every other, 10% of it being somewhat different and 10% being absolutely useless. That is not much room for differentiation. In my reading of these different approaches, the difference appears to whether the methodology was created by an SOA practitioner or merely a self proclaimed pundit.

For a prime example of the chest thumping echo chamber of ego and useless opinion, take a look at the yahoo SOA 'discussion' group[warning, Yahoo login required to view content]. Here you have a handful of preening blovators who go on at great length about esoteric, impractical aspects of webservices and (sometimes) SOA. Endless rants about REST vs SOA, business services vs enterprise services, their out pet definitions of technology terms, on and on. When an unsuspecting non-blovator posts, there is a veritable feeding frenzy to see who can dissect the question and turn it into a rambling thread of gibberish and self promotion. Thus, the majority of the non-blovator questions go unanswered leaving the poster to think, 'well if all of these smart people can't come to a reasonable conclusion, then it must be really hard'. Run away from the pundit mosh pit!

This is not to say that there aren't the occasional quality posts that provide some real value; there are. The problem is that there is so much noise that it is hard to find these nuggets. Just as there are some true practitioners you can go to to get quality information on a highly consistent basis. In my opinion, one of those (rare) individuals is David Linthicum. He consistently delivers the 'here is what works and here is what doesn't' insights that I really appreciate. I just hope that this continues to be the case now that he is part of the ZapThink group.

Right, then there is Zapthink. You really want their website to be the good resource for SOA that it desperately wants to be but visitors are immediately put off by the newbie web design motif that makes it look like a pr0n site, circa 1998. Arrive at the site and you are greeted with: A horizontal scrolling banner, and vertical scrolling banner, an obnoxious flashing banner top center, a font that is about 3 sizes too small to be legible and no real information on the front page, only self promotional come ons. It is a disaster. When you get to the 'content' (most times behind a login) it is typically an excerpt that you then need to go to yet another web site to read the actual article. Tedious and unnecessary, especially since many of the linked article merely mention Ron Schmelzer name and some quip that he contributed.

So where does that leave those in search of quality information on SOA? Here are a few of my favorites:

The previously mentioned Real World SOA blog by David Linthicum
SearchWebServices Occasionally has some good postings in and amongst the vendor diatribesn
Steve Jones' Service Architecture – SOA is worth a look, as wel
l SOA and EDA Though I wish Jack would ditch the annoying snapshot preview popup
SOA Consortium Insights is updated infrequently, but the posting are typically info dense
The SOA Magazine tends to have good, in depth postings
Todd Biske's Outside the Box has thoughtful posts on not just SOA but BPM and Enterprise Architecture in general
webservices.org can be a bit hit or miss, but you can usually pan a few nuggets away from the vendor annoucements and whitepaper-cum-advertising literature that you find there

Technorati Tags: soa, blogging, reference, webservices

So
Wikipedia defines a shanty town as:

... “marginal” or informal settlements are units of irregular, low-cost dwellings, usually on lands belonging to third parties, and most often located on the periphery of cities. These dwellings are often assembled from pieces of plywood, corrugated metal, sheets of plastic, and any other material that will provide cover.

This is what immediately sprang to mind as I read yet another article on IBM developerWorks that left me shaking my head. This one was on 'situational applications' which to me sounds like a euphemism for 'zero design hacked together crap that the enterprise has to deal with for the long term'. I've seen far too many of these things actually in production to have much positive regard for them. For those who favor the 'city planning' paradigm for Enterprise Architecture, situational apps are the shanty towns of the enterprise.

Someone needs to clue IBM in on this basic fact: any real or imagined efficiency in development approaches zero benefit in the overall lifecycle of an application. This effect is negatively magnified when developers 'just have to' use some new technology-of-the-week for their project (the veritable random pieces of plywood and corrugated metal of the software shanty town). Then, after the shininess has worn off, the application represents a one-off island of technology that the enterprise has to deal with. And deal with. And deal with. It is absolutely amazing that in the 'Challenges of SAs' portion of the article that cost is never identified – increased cost to support, maintain and (hopefully) decommission the errant development.

Overall, the SA approach sounds like a noble effort for a lab setting to see what benefits can be gleaned from the endeavor. Unfortunately, in many cases, the 'lab' will be the enterprise production environment. I have a feeling that SA will improve IT about as much as shanty construction enhances modern building techniques.

And please remember, the fastest path to the wrong answer is still the wrong answer.

Technorati Tags: architecture, design, developerworks, dubious, ibm, software

So
Google recently announced that they are supporting a pubsub model for sharing information between gadgets (their name for widgets). I think this is a very good thing in that it is a step toward building more composite functionality on a page by having multiple specialized widgets share information for a greater purpose. Think of it as mashups for widgets (mash-ets?, widg-ups?).

For whatever reason, the developers of the Java Portlet specification never seemed to catch on to the power of inter-widget communication.

Technorati Tags: gadgets, google, mashup, portlets, webdev, widgets

So
From Cnet:

In an effort to capitalize on the Java brand, server and software company Sun Microsystems will change its stock ticker from SUNW to JAVA next week.

Sun is making the shift because Java has far greater brand awareness than the company's name, said CEO Jonathan Schwartz in his blog on Thursday. The current symbol, which stands for Stanford University Network Workstation, reflects the company's origins but not its present, he said.

“The number of people who know Java swamps the number of people who know Sun,” Schwartz wrote. “JAVA is a technology whose value is near infinite to the Internet, and a brand that's inseparably a part of Sun (and our profitability).”

Sun estimates that 1 billion consumers recognize the steaming coffee cup symbol of Java, it said in a press release.

Using similar logic, Microsoft will soon be changing it's stock symbol to BSOD an 'innovation' for which it is well known and that people associate with the MS name.

Technorati Tags: sun, java, bsod, microsoft, stock

So
Ok, maybe the title is a bit strong, but it is the one thing that struck with me when I was reading through a posting on ESB-Oriented Architecture at IBM DeveloperWorks. This is the part that struck me:

Rather than the IT field of dream’s slogan of “if you build it, they will come,” a more appropriate slogan comes from Extreme Programming (XP): “You aren’t gonna need it.” This slogan is shorthand for a very practical principle:

Always implement things when you actually need them, never when you just foresee that you need them.

This principle—don’t build it until you need it—is the opposite of the IT field of dreams. Rather than building it because you hope that someone will want it, do not build it until you know someone wants it. Then you can make sure to build what they want, not what you think they might eventually want. And you will not incur the costs of building it until you are also ready to reap the benefits of having built it. This principle is just a good business philosophy, and it applies to the IT department as much as any other parts of the business.

This may have some applicability at a 'micro' level, say, when you are deciding whether or not to write a function or class — a task that may take minutes or hours. But, I think it absolutely misses the mark for larger scale efforts that might take months or years. I believe this posturing also reflects the disdain that the 'agile' and XP herds have for sound architectural principles. Coding is not architecture. Nor is it proper documentation.

A successful enterprise architecture strategy should reflect a robust enough understanding of the business that it supports to be able to anticipate when changes are needed and build them before the business actually needs them. This is how architecture adds value to the enterprise, not just to a project. However, if you enter into a reactive process where you are trying to build out significant infrastructure at the same time that a project or projects is intending to consume it you will likely fail.

To put it in the terms of the posting: the business would have come (and gone) because you couldn't build it fast enough to add value. And rare is the project that will just hang around for a year while you quickly try to deliver. Something.

Technorati Tags: ibm, architecture, badideas, developerworks, esb

So
Both of the things that I am about to suggest have been around for a while, but I think the combination of them is very compelling. First off, if you haven't already, read A Long Way Gone. Then watch the movie Blood Diamond (if you have already seen the movie, read the book).

While the story of the 'boy soldier' is just a subplot in the movie, the book does an incredible job of providing first hand insight into what it was like to exist in that mode. The movie really brings to life all of the things you read about in the book and provides more insight into that subplot in the movie.

Technorati Tags: boysoldier, conflictdiamonds , book, dvd, history

So
So what does 192 AA batteries get you? An 83.7 pound car with a top speed of 75.8 MPH and an average speed of 65.8 MPH.

Technorati Tags: battery, car, electriccar, gadgets

So
This is a rather stunning/shocking video of a Chinese made car absolutely failing a crash test at around 42 MPH. The car basically crumples in half and the crash test dummy takes it pretty hard. It costs $9000USD and you definitely seem to get what you pay for — not much in the way of safety.

Technorati Tags: cars, crash, madeinchina, buyerbeware