SOA myths

From Intelligent Enterprise, the top 5 myths of SOA:

  1. If you’re using Web services, you’ve achieved SOA.
  2. You can buy SOA out of the box.
  3. You can simply wrap legacy systems with services.
  4. Once the top executives are sold on SOA, your troubles are over.
  5. SOA is easy.

Check out the article for the details (not particularly meaty) on each.

I consider the last two myths to be self-evident for any type of non-trivial technology, so are a bit frivolous to be included in this list. The first three, however, I run across on a regular basis, and are good to keep in mind when evaluating what you’re doing with SOA, and what vendors are trying to sell to you. My response when I encounter these three myths:

  1. Web services is a set of specific technology standards for building interoperable components. SOA is an architectural and design philosophy that is typically implemented using web services standards, but doesn’t have to be.
  2. You can’t buy philosophy out of the box: “I introspect, therefore I integrate” provides design guidance, but it’s not a ready-to-go product (with apologies to René Descartes).
  3. I’m not so sure that this is a myth, since you could actually wrap legacy systems with services interfaces and they would become valid parts of your SOA environment. The point in the IE article is that maybe this is a good time to reevaluate the systems that you have and replace some of that old legacy stuff, but that’s not an SOA/not-SOA decision per se.

RedMonk Radio podcasts

I’ve been catching up on some podcasts lately — I subscribe to more than 20 via iTunes but only have a chance to listen to a couple of my favourites each day — and finally had a chance to listen to some of the recent RedMonk Radio podcasts from RedMonk, a small analyst firm. I like RedMonk Radio because it’s a conversation between the participants, rather than a formal interview or a standalone speaker, so it’s fun to listen to as well as informative (I especially like James’ imitation of American accents 🙂 ).

In episode 6, James Governor and Michael Coté talk about SOA testing, and the specific problems of testing the heterogeneous SOA environment that most organizations have that includes legacy systems and newer services. There’s a great bit where James states “EAI and SOA are not the same thing, but on the other hand, some of the concepts of EAI, some of the approaches and even some of the technologies are relevant.” Coté asks “What do you think the differences are between the two?” James responds “$40,000 per CPU” (referring to the former market for expensive adapters and connectors that have been replaced by standard web services interfaces), which completely cracked me up. Also some interesting thoughts on testing when some or all of the software/services are outsourced.

In episode 8, Scott Mark interviews James and Coté about life as an industry analyst, which is really about the small-firm analyst experience: I’m sure that things are much different for Gartner analysts, for example. The outside view of analysts is much more glamorous than the reality, but these guys are obviously in it because they have a passion for it, not because they’re making huge buckets of money at it. The funny thing is that the typical day that James described for himself is much like what I do: customer/prospect followups, industry research, reviewing blogs, vendor briefings, writing vendor and technology reviews, and consulting. Maybe I’m an analyst in disguise.

Gartner podcast on EA leaders

A good 9-minute podcast from Gartner on the role of enterprise architecture leaders, featuring Robert Handler, one of their research VPs. He spends some time discussing how an EA role is more than just IT:

“It’s become a truly leadership role, one that involves strong communication skills and fundamentally bilingual capabilities, being able to speak both business and IT.”

Handler mentions that the EA role often includes aspects of process optimization now. He also says that although EA’s have moved up from reporting a couple of levels below the CIO to reporting directly to the CIO, that they should really be reporting to the CEO — something that I’ve posted about previously. Lots of good stuff on who the enterprise architect should be forming strong relationships with, in order to help foster architectural alignment throughout the organization.

Update: there’s also an EA-related podcast from Macehiter Ward-Dutton, a UK-based consultancy. The first part is unrelated industry news analysis, but there’s some EA bits based on a discussion that Neil Macehiter had (offline) with James McGovern starting at the 23-minute mark. Apparently, they’ll be having McGovern on the podcast later this month.

DemoCamp

I attended TorCampDemoCamp5 this week, my first DemoCamp and a great opportunity to see some new stuff, meet some new people and catch up with some acquaintances. The popularity of this forum is amazing: there were probably 130+ people there, some of them sitting on the steps of the lecture hall since there weren’t enough seats for all.

Best quote of the evening, from one of the presenters (sorry, can’t remember who at this point) when asked why he had developed the code in Rails, responded “It was like this code wanted to be written in Rails”, which evoked some laughter and a round of applause.

The most interesting presentation (to me) was DabbleDB — unfortunately not yet available — that did some of the coolest stuff with structured data that I’ve seen in a long time, like dynamic normalization and some really intelligent typecasting including calendaring based on data range fields. It’s not often that data manipulation can make me raise my eyebrows and declare it as cool (otherwise, this blog would be called Column 1 instead of Column 2), but this actually provides a potential path to putting some structure around and sharing all of that data that’s currently sitting in spreadsheets. You can read an independent review of DabbleDB here, watch a seven-minute demo (highly recommended, and similar to what was shown at DemoCamp) or a 40-minute presentation, or check out their blog. Written in Smalltalk, a language that I haven’t even thought about in years.

Also of interest was Unspace’s datagrid, a very Web 2.0 way of capturing and presenting formatted data.

Unfortunately, I had to head home and finish my taxes instead of heading off to the pub with the group afterwards, but I did have a chance to meet face-to-face with Markus Strohmaier, a Column 2 reader from Austria who is now in Toronto for post-doc research in his field of business process-oriented knowledge management. He initially alerted me to the BPOKI track at the International Conference on Knowledge Management.

SOA education

I listened in on an ebizQ webinar today, The Path to SOA Enlightenment, and some interesting points came up about SOA education. The sponsor of the webinar was the Integration Consortium, which of course has a vested interest in encouraging SOA education since they already offer training and certification, but there’s few who would disagree that we need better education about a number of integration-related areas. Here’s a few screen snaps of the audience survey responses gathered during the webinar:

The first of these allowed the audience to select more than one response, while the second only allowed the selection of a single reponse. The two above make sense together: if people think that it’s the integration specialists and architects who most need certification, then it follows that the biggest area of training would be concepts rather than technologies.

The next one, which also allowed more than one response to be selected, shows the topics that people feel are important in the training, and there’s a few surprises here, such as organization, policies and governance in first place with 88% of the vote. SOA design and standards almost tied for second with 75% and 73%.

The audience also responded that although only 34% of them have an integration or SOA methdology in place, 87% are interested in having one.

BPEL: just another language

Phil Gilbert’s post last week exposes the Emperor’s clothes for what they are: BPEL is just another implementation language:

It’s simply a new way to write code. It has nothing to do with the management of business processes. I don’t love it or hate it; other than that it is a distraction. BPEL isn’t necessary to achieve the benefits promised by business process management – and therefore it’s an impediment in the market conversations that are occurring with respect to business process management.

Yes, BPEL can make writing code to implement BPM easier, but don’t confuse that with anything to do with managing business, or with anything that allows the control of business processes to be moved into the hands of the business.

BPM Think Tank

I’ve just registered for the OMG‘s BPM Think Tank in Washington DC on May 23-25. The program is mostly about standards, which is a big focus for me right now. It will be a chance to see some people who I’ve met before, such as Phil Gilbert and Derek Miers, and meet a few others for the first time face-to-face, such as Bruce Silver, Keith Swenson (who I heard speak at the Gartner BPM Summit) and John Evdemon (who was referred to me by Harry Pierson when I met him at Mashup Camp).

If you’re going, look me up. If you haven’t signed up yet, discount registration fees for the BPM Think Tank are still available until May 1st.

OMG gets full marks for including bloggers when they’re handing out press passes; my thanks to Dana Morris and Stephanie Covert for their forward-thinking press relations policies. I’ll be blogging more about the event before, during and after.

Document, document, document

Phil Wainewright posted one of the IT commandments today: Thou shalt document all thy works. This is a perfect followup to my post yesterday about SOA and data, although it may not appear obvious at first. Problem: application developers don’t use services when they should; in yesterday’s post, I was talking about how they squirrel away data in their own application-specific silos, but the real issue is more widespread than that. Wainewright hits it on the head:

Failure to document is thus one of the biggies of ZDNet’s IT Commandments, high up in the mortal sin rankings with the likes of ‘Thou shalt not kill’. For if you don’t document your work, how is anyone else supposed to reuse any of it? From your greater sin flows a multitude of others’ lesser transgressions.

In addition to yesterday’s more easily defeated arguments that developers don’t use services because the data may not be accurate or it make take too long, we add this one that’s harder to counter: the developers don’t use services because they’re not properly documented. This is often blamed on developers having a “not invented here” attitude, and wanting to build everything themselves, but I disagree (in general).

I’ve been a developer, and I used anything available to me as long as I understood how to use it, how it worked, and its limitations. In other words, I used third-party code/services if they were properly documented, and I could determine from that documentation that they suited my needs. If they weren’t documented and I had to walk through the code (if that was even available) to figure out how it worked, then I was more likely to just rewrite it myself, on the basis that if someone couldn’t write proper documentation then maybe they couldn’t write proper code either. Later, when I ran a development team, I made the developers write the documentation first. They bitched about it, but we had a high level of code reuse.

There is no way to achieve SOA without reusable services, and there is no way to achieve reusable services without proper documentation of those services.