SOA Zone

Yes, I know my blog postings have tailed off significantly.

One of the reasons is that I found out that my ISP has imposed "security restrictions" on my blog that make trackbacks and announcements of my blog entries impossible.  Of course, if I only pay an extra $50/month they will remove these "security restrictions".  Funny how more revenue seems to make security risks magically disappear.

Anyways, because of this, I'm now blogging in a different place (if you want to see just my blog entries, you can click on my mug on the left hand side of the page).  And, I am trying to increase my blog frequency. See you on the other side.

By now there are lots of different "maturity models" for SOA - virtually every vendor and analyst has one (which isn't surprising).  What is important, though, is that all of these are pointing to the same thing: most companies adopting SOA are hitting a glass ceiling they can't get beyond, regardless of which maturity model you look at.

Most are getting stuck at the same place -- at the levels of the model below where business value and alignment are anticipated.

What's causing this?  Here's my take on it...

I came across an article in Government Computer News today by Jeff Simpson (the chief integration architect in BEA's government practice) that said:

"The politics of SOA [in government] will most likely be quite simple".

I couldn't believe my eyes.  I had to reread it multiple times time see if that's what it really said.  I have to say that strikes me as astoundingly, almost unbelievably, naive.

As a vendor that has products that focus on SOA security, it's pretty easy to slip into the mindset that buying security products is all that's needed to cure a company's security problems.  I thought I'd tell a story that happened to me in the last week dealing with an internet mortgage broker company (not a customer of mine!). You know the kind: the ones that "compare and act on up to 4 customized offers instantly".  The moral of this story is that it's not all about having security products - security needs to be core to your IT culture.  Anyways, here goes...

I subtitle this blog entry "why 90% of mashups use mapping"...

There's been a lot of talk recently about Web 2.0 and how it might apply in enterprises (and, as a result, how it overlaps with SOA).  I'm a big believer in simplicity and agility, and so I like a lot of the Web 2.0 concepts.  But I think most people are underestimating what it will take to adopt technologies like mashups in an enterprise setting.

It's been a tad busy for me recently, and so I've fallen behind on my blogging and wanted to get back into the swing of things with an off-topic topic I've been musing over for a while: How the IT industry and the fashion industry are kissing cousins.  You don't believe me?  Well, read on...

As some of you already know, my company, Actional, has been acquired by Progress Software.  I thought I’d give my perspective on this, as someone on the inside, for those interested.

In many ways, AJAX changes the model of how web browsers are used.  Instead of delivering "finished" content to the browser which just needs to be rendered, in many cases the server will deliver an XML document to the browser - and this document will be processed by JavaScript (or similar language) to generate page content locally.

Regardless of whether you use web services to serve the XML or you use REST services, in either case the success of your project depends on how you design the interfaces to these services.

With the advent of AJAX, asynchronous is all the rage.  If you're not familiar with AJAX, if you've used Google Maps you've seen AJAX in action - it's what allows the map to be updated while you are doing other things on the page.

I've heard a number of people recently take this as proof that asynchronous messaging is the "right" way to communicate.  Too bad they are comparing apples to oranges.

While that's interesting, the real important topic to discuss is how the use of AJAX changes the way you need to think about designing services...

... is that there are so many to choose from.  At my last count, there are now somewhere well above 50 proposed standards related to SOA and web services.  Here’s a short list of some of the ones you might have come across...

XML, XML Schema, SOAP, WSDL, UDDI, BPEL, XKMS, WS-Policy, WS-MetaDataExchange, WS-SecurityPolicy, WS-Addressing, WS-Trust, WS-Federation, WS-Secure Conversation, WS-SecureExchange, WS-Privacy, WS-Authorization, WS-Transfer, WS-Addressing, WS-Reliability, WS-ReliableMessaging, WS-ReliableExchange, WS-Notification, WS-BaseNotification, WS-BrokeredNotification, WS-Topic, WS-Eventing, WS-Enumeration, MTOM, WS-AtomicTransactions, WS-BusinessActivity, WS-Coordination, WS-Composite Application Framework, WS-Coordination Framework, WS-Transaction Management, WS-Context, WS-Remote Portal, WS-Resource Framework, WS-Resource Properties, WS-Resource Lifetime, WS-BaseFault, WS-ServiceGroups, WS-Inspection, WS-Discovery, WS-PolicyAttachment, WS-PolicyAssertions, WS-Provisioning, WS-Manageability, WS-Distributed Management, WS-Choreography, WS-Choreography Description Language, HTTPR, WS-I basic profile

With so many to look at, how do you make sense of them?

Gartner released their 2005 hype cycle a few months ago, listing SOA as having entered the trough of disillusionment.  True to this prediction, a recent article by Charlie Babcock of Information Week states that sometimes SOA adds complexity rather than simplicity.

Up front it says 1/4 or respondants have said SOA has increased complexity. Bad news, of course, sells better than good news.  You don't find out until later in the article that 69% said that SOA or web services met or exceeded expectations.  That number is, frankly, really good for any new IT initiative.

Shockingly, the article also states that, to be successful, IT needs a clear understanding of employee and customer needs.  What, you mean adopting SOA blindly without understanding your business doesn't work?  This alone could explain the 1/3 to 1/4 that are having issues.  Successful SOA isn't a technology initiative - it's a business initiative backed up by IT.

But, this survey is actually very interesting.  If 69% of people say SOA or web services are exceeding expectations, does this mean we're through the "trough of disillusionment"?  Maybe, maybe not.  The issue is that Information Week have bundled "SOA" together in the same question as "web services."  So, it's hard to know what the Information Week numbers really mean for SOA.  Hopefully they (or someone else) will do another survey soon that tries to isolate web services from SOA to give a more meaningful set of numbers about SOA.

Single sign-on systems (or identity management - IDM - as they now like to be called) are an important element of an SOA strategy.  Some have even referred to them as the Holy Grail of SOA security.

While I agree that they serve an important role (especially from an end user perspective - avoiding multiple logins), it's very easy to take them too far and, as a result, end up with a horribly complex unmaintainable SOA.

A question posed about the article I wrote on ESB vs. SOA was to compare a "message oriented architecture" (MOA) to a "service oriented architecture" (SOA).

There's no well recognized definition for MOA, frankly.  Many people talk about it interchangeably with messaging middleware, but I think that's a mistake because middleware does not prescribe the architecture of the applications layered on top of it (you can do point-to-point, SOA, pub/sub, request/reply, etc. on top of a messaging middleware)

I would tend to describe it as follows...

It seems that "ESB vs. SOA" is becoming the new religious war, just like "windows vs. unix", "J2EE vs. .NET', and more obscure ones likes "COM vs. CORBA".

Seems like everyone is weighing in.  David Linthicum gives a good summary of some of the recent activity in this blog entry of his.

Always interested in a good argument, I published an article with a different spin on this recently in ComputerWorld.

There were a couple of good questions on my last blog entry about policy:

• Can you compare and contrast policy with standards
• How is governance tied to policy
• How do you enforce policy

I'll try and answer them here...