Archive for May, 2009

muSOAing for 5/28/09

May 29, 2009

We have been focused too much in the tactical aspects of SaaS and SOA. While this good, we should also think ahead and see what would be required to keep this nice SaaS and SOA infrastucture we have built to keep humming along like a well oiled machine. Say Hi to SOA Runtime and SOA Governance. This is really a topic for serveral future muSOAings so will not be talking about it now.

Back to BPR. While the need for Process Orchestration is quite pervasive, choosing and implementing a futureproof strategy for this is quite critical. So how would you go about doing this. First you will need to draw up your list of requirement in terms of what you want to achieve through Process Orchestration and then you will shop around for the best of breed products out there to bring all these plans to fruition. Planning to build one yourself? Don’t be crazy and get carried away, there is not such thing as building your own Orchestration engine. The good news is such engines have not been commodotized yet.

Stay tuned.

Advertisements

muSOAing for 5/27/09

May 28, 2009

Before we delve too deep in to BPR, let us examine for a moment what constitutes a Business Process. Business Processes have been in existence since the very first computer program was written. Any unit of work that requires access to multiple touchpoints can be described as a business process. While early processes were marked by their homogeneity, for instance written entirely in COBOL or in a 4GL such as PowerBuilder (an abstraction over the Windows SDK), the newer ones introduce certain new paradigms.

For instance, take one of the new kids around the block Weblogic Integration, not only does it amalgamate and act as an abstraction over the J2EE stack, it brings together concepts such as asynchronous interactions (JMS), Parallelisms (Threads) and long running transactions (Process Dehydration) to mention just a few.

So you consider products such as WLI to be on the bleeding edge of Process Orchestration? Nope, there is yet another frontier that is being conquered in this space. Stay tuned.

muSOAing for 5/25/09

May 25, 2009

So what do you mean by BPR (Business Process Rationalization). It is hard enough to implement business processes to cater to your own business let alone extrapolating that a 100 times out to service multiple clients. Whenever the word Business Process is bandied around the first technology that comes to mind is a Business Process Manager or BPM as we like to call it.

So will a good BPM engine aid you in BPR? Not really, when you bring BPM into the picture, you are implicitly assuming that all of your interface touchpoints are indeed webservices. Alas that is sadly not the case. BPM still has it’s uses mind you but just not for BPR. BPM is typically used by Business Analysts to draw up composite business processes by composing two or more services to serve a specific business function such as Order Fulfillment etc.

So what is the best way to implement BPR. Stay tuned.

muSOAing for 5/24/09

May 25, 2009

My memorial day muSOAing. continuing our discussion on SaaS. This concept has certainly evolved. There are so many flavors of SaaS that it is now quite hard to define definitively what is an ideal SaaS platform. All said and done, I think an ideal SaaS platform should at the least possess these basic charasteristics,

1. Single App Instance
2. Co-location of multiple clients
3. A generic DB design that would support point #2
4. A robust Portal framework that allows for easy customization and personalization for
the various co-located clients.

The client who has outsourced a business function to you does not really care or dictate that you follow these SaaS principles. All he wants is the functionality that was hitherto being performed within his firewall/intranet.

There is one critical piece we left out that should have been point #5 in that list. What is that? Apart from the customization and personalization features that can be implemented by a Portal there is this domain of business process rationalization. How do you accomodate in as generic a way as possible, the various business process needs of these various co-located clients. Well, that would be a topic for my next muSOAing.

muSOAing for 5/13/09

May 14, 2009

Continuing our discussion on SaaS, there have been different models that have been tried out starting with DIY SaaS (which is till very prevalent) to hosted clouds from the likes of Rackspace, Amazon etc. So what is your optimal SaaS platform? I think it is not a very hard question to answer.

It really lies with who is in control. Do you have any control on the platform deployed on the cloud? If this is of importance to you then it is something to consider. So what is your utopian SaaS infrastructure, will it be addressed by PaaS? Maybe and that depends on what you really want to achieve with SaaS. Dropping a cliche, there are several ways to skin a cat.

This conversation is getting more interesting by the minute, stay tuned.

muSOAing for 5/9/09

May 10, 2009

Another small segway. Actually not a segway cos what I will ponder upon is also related to SOA. I am talking about SaaS. I frequently drop this term “SaaS is outsourcing on steroids”. Is that not true? You take a particular function however mundane it may be and you totally automate it and to top it all host it in Timbuktu. Not only that, you take some pains to co-locate multiple clients in the same app instance.

So how is SaaS related to SOA. Very much I say. In fact they are like long lost brothers who have found each other akin to a script of a yesteryear Bollywood flick.

Now there is a lot we can talk about wrt SaaS and why not. So in my next few posts I will be talking about SaaS and how closely it is related to SOA and how it is a marriage made in heaven.

muSOAing for 5/2/09

May 3, 2009

Took a long break there. Got caught up with work. So now we are cruising again, let us talk a little about canonicals. So before we begin, what is a canonical? In simple terms, a canonical is something that everyone in the organization agrees upon as a standard and with respect to SOA, it usually refers to a schema that may represent some business function such as an Order or a Trouble Ticket.

As easy as it may sound, coming up with a canonical is one of the toughest tasks in the long road to SOA. There are some verticals that have been proactive and have come up with their own such as RosettaNet, Oasis, HIPAA, OTA etc. but that does not mean that the job is done. Gaining acceptance among all the organizations that play in that vertical is very difficult unless they have played an active role in the formation of these. Normally driven by a .org with a host of very good people shepherding the process along (thank you all).

Stay tuned……