"We didn't start the fire ... it was always burning since the world's been turning ..." [Billy Joel 1989]. Is SOA the "Same Old Architecture?" or is it "Simply Over Ambitious?" Let's apply SOA's arsenal:: XML, BPM, Services, SOAP, Web Services - to the real world and find out. Let's put out some fires.

« August 2006 | Main | October 2006 »

September 24, 2006

Research Dimensions of SOA - pt 2

In continuation of past post on research directions in SOA, one key issue that often bogs the enterprise integration architects is the balance between realistic integration solutions and hyped approaches like the next IT wave.

In that context, events are a natural language for EAI practitioners to understand. Read on..

While events have a background in EAI infrastructures, the next generation integration infrastructures are more closely tied to SOA. Is there an intersection between events and SOA.

 The new found paradigm of event driven SOA holds promise for some of the ongoing efforts in amalgamation efforts between EAI, ESB and SOA. One crucial research direction we are pursuing is the research dimension of event driven SOA.

In that context again high performance event driven middleware becomes crucial for enabling event driven SOA to become mainstream. We are investigating SEDA based concepts to see if high performance event driven SOA can be achieved. Read the paper on SEDA and its role in NMS at http://nwesp.org/ijwsp/2005/vol1/15.pdf

 

Next research direction in the next post...

The bumpy road to an ‘open’ SOA : analyzing the open specifications and their state

Open specifications or standards make Service Oriented Integration (SOI) different from other strategies such as EAI. As usual, fortunately or unfortunately, there are many standards; standardized organizations/consortiums are trying hard to reach into consensus on SOA related standards. OASIS, WS-I and W3C are the three prominent consortiums. These standards are different stages of their maturity.

Due to this, IT organizations are facing many challenges in adopting these.Some of them are


1) If there are overlapping subject areas among two standards, how to select between those (e.g. Eventing vs. Notification)?
2)How to proceed with a standard when currently, the product/tool vendor’s adoption is low, but there is a defined adoption roadmap from vendor? When there is no defined roadmap, it becomes another level of issue.
3) When a specific standard (e.g. BPEL4WS) is extended by a vendor (e.g. IBM), what should be the internal IT strategy? 1) adopt the vendor extensions or 2) limit to the standard?

There questions are just the tip of the iceberg.  Midst of this confusion, there are many interesting happenings, which are promising, many times unconventional. As an example Microsoft promises 'not to assert' claims to 35 Web services patents, including SOAP, WSDL, and many WS-* specs.

To the question of ‘Why did Microsoft take this approach?’, Microsoft answers ‘It was a simple, clear way, after looking at many different licensing approaches, to reassure a broad audience of developers and customers that the specification(s) could be used for free, easily, now and forever.’ Fair enough; no body can disagree!!!

Midst of industry predictions on SOA related patent wars, the above might be a good news.

In the future discussions, I would be analyzing the subject area of individual standards or   positioning, level of maturity and adoption.

September 19, 2006

Is there a research dimension in SOA?

1 Quite often IT waves which trigger a huge hype initially, followed by a more realistic expectation setting among practitioners, the real gaps needing deeper research and insights, come to the fore.

At this moment, SOA is slowly moving from hype to reality. In this transition, apppear like a pandora's box the enormous challenges which can aid practitioners adopt SOA realistically and practically.

At Infosys SETLabs, we are constantly working on research directions to help practitioners adopt SOA with a realistic and practical approach.

To list these areas:

Enormous opportunity lies in enabling legacy environments to become first class citizens via SOA. A huge amount of our research effort is directed at enabling legacy environments to be part of mainstream SOA

 

Listen to the related webinar at https://infosys.webex.com/infosys/onstage/tool/record/viewrecording1.php?EventID=361197629 

 Also see a related paper at http://www.infosys.com/rd.asp?pg=http://webservices.sys-con.com/read/164558.htm 

More research areas in next post

 

Value dimensions of SOA explained

Explaining the value dimensions and examining the measurable sub-dimensions.

 

 

In the previous post we started off with defining the value dimensions of SOA and the need for understanding the value dimensions of IT architectures. In this post we shall go a little bit deeper into each of the dimensions listed. Expansion of the high level value dimensions into measurable sub-dimensions is important to capture some of the benefits. Organisational value dimension has time to market and support for emerging scenarios as the key sub-dimensions. Business Process value dimension has sub dimensions such as modifying existing business processes and cost and time of introducing new business processes. Technology value dimension has sub dimensions such as interorganisational collaboration, loose coupling, reduced complexity and ease of integration, reduced cost and time of internal integration, partner integration (customers, vendors), reduced cost and time of introducing new applications, modifying existing applications, reduced cost and time of introducing new IT infrastructure, modifying existing IT infrastructure and scalability of systems. Standards value dimension has benefits from low vendor lock-in and platform and technology independence as sub dimensions. Re-use dimension has re-use of infrastructure, re-use of business models, re-use of processes and re-use of applications as sub dimensions. People dimension has IT personnel efficiency and standardised employee skill-sets as sub dimensions.

 

 

In the next post I will go into the results of our research which looked into the relative importance of each of these value dimensions as well as sub-dimensions.   

 

 

September 04, 2006

Value dimensions of SOA

Architectural approaches such as Service Oriented Architecture (SOA) are transforming the way IT systems are designed by bringing in a high degree of reuse and loose coupling of applications. This opens up avenues for organizations to deliver their services in new and effective ways to their internal and external partners. Value dimensions and measurable sub-dimensions of IT architectural paradigms such as SOA in enhancing business value is a key area of interest. Value dimensions are the ways in which value is instantiated. In the context of our discussion, value dimensions are the values or benefits which IT architectures present. Understanding the value dimensions of IT architectures is important as they typically involve large scale changes and such decisions need to be supported by the benefits which they generate. Based on our research, we have identified six value dimensions of a services based architecture. These value dimensions are organisational, business process, technology, standards, re-use and people.

 

More on these value dimensions in the next post.