Archive for February, 2011

muSOAing for 2/28/11 – ROI, TCO and all that good stuff

February 28, 2011

Services foster a business first approach. So one should attempt services design from a BPM perspective. Think about the big picture first and then worry about the minituae later. So the first thing to do would be to consider that process that is proving to be the most expensive to maintain for various reasons. It could be that it requires a lot of people to maintain, enhancements take a long time and the resultant feature cannot be reused so all said and done, the TCO for this business function is very high.

Now look at this from a holistic fashion and think along the lines of a SOA based approach to replatform thiis same business process. You basically want to achieve the same function at the end of the day, it is just that you want to eliminate all the inefficiences inherent in the way it is done currently. So if you lay down the yardsticks for the future vision for this process and adopt a SOA based approach then all the rest of the details take care of themselves. A business process can be as complex as something like Order to Cash or something as simple as accepting service requests through the web.


tmuSOAing for 2/21/11 – service or not a service is the question

February 21, 2011

We all know by now that while SOA does begin with services, it certainly is not the be all and end all of a Service Oriented Architecture. Services do provide the bedrock and foundation for SOA. To manage it and take it to the next level, a lot more is needed in terms of Governance, BPM and EDA to just name a few.

Before we are led astray, let us examine services a bit more in detail. While a service may be viewed as a function or API that can be called from the web, it can abstract a whole lot of elements that the consumer of the API may not be and need not be aware of. Just imagine the number of boundaries you are crossing when you invoke a service from say Bangalore, India (Yes Bangalore and not Bengaluru) while the service is hosted in Mountain View, CA. Just off the bat, at least four come to mind, Geographical, Organizational, Network and Transactional. You are a one man shop and building an application with the Google App Engine.

Now let us move on to more interesting stuff. The actual design of the service. So what parameters should one consider when building a service. These days with SOA frameworks embedded in almost every hub and spoke system, the temptation is to expose every tiny function as a service, the so called right click syndrome. That may work when you are the sole consumer for those services but when you are talking enterprise services or international services, it is a whole different ball game. Service design becomes even more critical and it has evolved into it’s own art form.

muSOAing for 2/8/11 – SOA and BPRE

February 8, 2011

One of the key USPs for SOA has been it’s ability to revolutionize Business Process Re-engineering. SOA has become so pervasive that what had been the exclusive preserve of middleware integration technologies or the so called hub component of the integration puzzle has now proliferated to the spokes. Every EIs system worth it’s salt is now packaged with inbuilt SOA frameworks to enable two way service interactions and do away with arcane adapter based point to point interfaces that are hard to build, maintain and enhance.

So what’s all this buzz about BPRE. Well, at the end of the day, all your IT systems boils down to business processes you implement to run your business efficiently. SOA is again key to this as it fosters a business first paradigm. Your business process can be as simple as exposing one very discrete function like get today’s ARM rate to a very complex process orchestration spanning several functional silos and that may inturn be comprised of several sub processes.

When there is this problem of plenty, service design becomes even more critical so much so that it has evolved into it’s own art form. Service design in terms of how coarse or granular should a service be is very crucial. While a service design may look very good on paper (or Visio), it may fall flat on it’s face when actually implemented so a lot of thought has to be given to key aspects such as Service Level Agreements. Every consumer of your service is a customer and can dictate what the SLA should be. Other curve balls such as rolling out a new version of the service that not all consumers are ready to adopt leading to service versioning. SOA is hence a key technology that can not only address the business requirements but also key technical aspects which we shall examine in more detail in our next muSOAing.

muSOAing for 2/7/11 – SOA and ROI

February 7, 2011

While I have already stressed several times that SOA promotes a business first approach to solving any kind of IT need, be it a simple and granular function or a highly composite business process spanning several functional silos. One critical aspect that one has to keep in mind is the one that relates to overall ROI. I am sure not all folks are jumping on the Services Everywhere bandwagon just because it is the in thing to do. IT managers have long ago realized the advantages of SOA and a comprehensive Service Oriented Architecture.

They are just kicking this up a notch to the next level. In the current landscape, just having services deployed is not enough, there needs to be more. One of them is a holistic view on how to have a Comprehensive SOA strategy by incoporating Governance, EDA and BPM to round it off and the other key aspect is of course ROI. SOA is one of those technologies that lets you measure tangible ROI. One of the important components of ROI is TCO which in turn has several sub elements such as, cost of maintenance in a business as usual fashion, cost of upgrades, building new interfaces, staff training and skill sets, staff retention etc. The other aspect of ROI is what the “C” level folks are interested in, one of which is of course the sum total TCO but also ones that have much deeper implications such as business agility, advantage over competitors etc. SOA again has mechanisms to address this through the comprehensive and well rounded strategy that can be guaged by the SOA maturity model and measure against it.

While it may seem that it is possible for folks to bite off more than they can chew, this is a real possibility though, one can easily avoid these pitfalls by adopting a Holistic approach to the whole strategy. While at the outset, it should be a strategic one with buy in from all the key stakeholders including the SOA champion who controls the purse strings, it should be supported by several tactical initiatives to get buy in from the IT managers and the foot soldiers who are rearing to go and make this vision a reality.