Archive for April, 2010

muSOAing for 4/22/10

April 22, 2010

As described in my previous posts, services design and development being a very structured and streamlined process on one hand and Portal Development being essentially a RAD driven function, they are poles apart when it comes to timeliness and synchronization. One answer to this conundrum could be, start Portal development to align with delivery of services but this is easier said than done.

The needs of any organization big of small are such that development timelines are strictly aligned with budget allocations and consumption and department and SOA heads are not at liberty to dictate in most cases the granularity of project plans. The needs of an organization are greater than the needs of a department.

Now back to our original issue, how do you prevent the cart before the horse issue. Simulation has turned out to be the only answer to this. The next question that comes to mind is, whether to build or buy. There are several attractive offerings out there that can achieve simulation but before you get wowed by their features, take a moment, actually several days to come up with your list of simulation requirements and then do a detailed evaluation to see if these tools really fit the bill. The reason I am saying this is because, these tools do not come cheap and for the price you pay, the features they provide is woefully inadequate to your needs so in most cases you are better off building this framework as you then are at liberty to customize, enhance and are in total control of your simulation environment rather than having to deal with a black box product that does not let you customize of enhance.

In our next post we will discuss the key features you need to take into consideration when evaluating simulation tools.


muSOAing for 4/10/10

April 11, 2010

Continuing our conversation on Simulation. The importance of using a Simulation framework is not realized until you see the enormous gap between the time taken for UI Wireframe design and development and actual services development. With the availability of RAD tools UI Development has become a sort of a cottage industry. Portal and Rich UI frameworks abound and each offer a plethora of features that make it unnecessary to even write or examine a single line of code. Everything can be achieved through rich drag and drop palettes and widgets.

Not so the case with services. Services design is a more long drawn process as it involves several key steps such as Services Identification, Canonical and Schema identification, Functional Process Design, Mappings to end systems and finally services implementation. Once these key steps are achieved, then the development of the actual services and associated processes can be automated by implementing factory oriented patterns.

It is to mitigate this gap between the two that simulation becomes critical and necessary. In the next muSOAing we will discuss how to approach simulation, build vs buy, simulator design and tools.

muSOAing for 4/3/10

April 4, 2010

I want to take a moment and talk about the need for simulation in a SOA implementation. In fact, I think it is a blessing in disguise that Simulation can be implemented for it’s rightly intended purpose in an almost seamless and neat fashion.

I always like to make my argument or point by taking a valid use case. This however will have to be a fairly condensed one. I want to take a an actual scenario that I have run into repeatedly in every SOA implementation and that is the horse is ready but the cart is still being designed and built. The horse in this case being the Presentation layer and the Cart being the web services layer.

It has been my experience that wireframes required for the UI can be turned out fairly quickly with even just the basic elements needed for data capture and submit and w/o all the other bells and whistles. Services development is however another story altogether. It is no secret that the groundwork needed to build a service the right way and that is using Industry standard canonicals has a longer turn around time, typically 2-3 months behind the wireframe.

The conundrum however is you cannot leave the Portal team idle twiddling their thumbs so the obvious answer here is the use of a Simulator that is almost the real thing, one that you can swap in and out seamlessly.