Service-Oriented Architecture

Composite Application presents a new paradigm of application development which promises minimal writing of custom code and enables a business functionality through assembly of ready made components and services “harvested” out of existing enterprise applications and resources. These reusable assets have extension and configuration features or context, which need to be initialized while deploying the asset. Once deployed these would interact with the pre-exiting enterprise application through standardized interfaces and enable a new business use case or scenario. Since the new composite application is built out of pre-existing components and services after customization, the time to market is drastically reduced having obvious implications for the business. Having said that, these new breed of applications have a varied scope and touch points with diverse applications having different security mechanisms and models, database models, transaction models and so on. Hence, the composite has to take care of this distributed aspect which is not quite a simple thing to do.

 

Composite application building is not a new phenomenon, and most IT organizations have been undertaking this in a limited way. The maturity and open standards based seamless interoperability of tools and platform suite from most vendors have brought the vision of composite application closer to reality, along with a wider acceptance. Perhaps the most significant factor which has lead most vendors and clients to embrace seriously this style of development is the emergence of SOA principles, patterns and methodologies and tools based on SOA principles. SOA encourages modularity, standardized interfaces, reusability, open standards, etc. SCA is an open standard which is destined to play a big role in composite application development space http://www.osoa.org/display/Main/Service+Component+Architecture+Home. Composite application development style thrives in the presence of standardized enterprise models and modularized components having well designed interoperable interfaces. In order to facilitate the composite application development, quite a few of the big names among the IT product vendors have started providing out-of-box components, services, adapters and connectors which are specific to industry vertical domain such as healthcare, telecom, manufacturing, banking, etc. These reusable assets are usually based on industry specific open standards (information models, message models, etc.) and hence promise maximal interoperability.

 

Posted by Sudeep Mallick at 08:20 AM | Permalink | Comments (0) | TrackBacks (0)

While SOA has emerged as a panacea for integration owing to the standards based interfaces to applications it advocates. The complementary trend of Web 2.0 is promising the extend the reach of SOA to newer unexplored frontiers, like client side SOA, rich service consumer ecosystems, lightweight SOA etc.

 

However, as of now there are very few standards in the Web 2.0 world. Will standardization be the spoilsport in creation of this extended Web 2.0 - SOA interplay?

The fact of the matter is that the standardization efforts in Web 2.0 are still to pick up momentum, though initial efforts are on at W3C and OpenAjax Alliance. From richer standards within the lightweight models, some candidates for standardization in Web 2.0 include metadata within RSS/ATOM/JSON, standards for common data elements, standards for non-functional requirements like security in REST interactions, etc

 

In light of this, as pointed in http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1278423,00.html standards might be the spoilsport in the maturing of the Web 2.0 SOA interplay either via richer service ecosystem emergence, utlization of Web 2.0 for business directed mashups (a closer BPM -SOA possibility like Sohrab points in his earlier entry), emergence of practical lightweight SOA interaction models, etc..

 

 

Posted by Dr. Srinivas Padmanabhuni at 08:21 AM | Permalink | Comments (1) | TrackBacks (0)

Around Nov/Dec 06, I was listening to the SOA insights podcast where there were several views on SOA, Web 2.0 and BPM and whether there is interplay. This was around the same time as Oracle Openworld Show. There was the panel of Steve Garone, Joe Mckendick and Neil Macehiter and there was lot of discussion on the synergy, whether or not they understood each other and most important- were they complementary or competitive. At around this time at Infosys we had already put together our SOA viewpoint and built our delivery capability and won some great references.

Fast forward to Nov 07 we find that SOA and BPM are progressively getting tied at the hip. Many SOA projects are actually getting funded by opportunities of BPM in terms of simplification, optimization and automation. The reason why Oracle Openworld 07 came to fore is not only that it is current in San Francisco, but both Oracle and SAP have been putting all their development money behind SOA architectures and reference models with emphasis on process models which have been the core of ERP packages.

The industry is very excited about the integration of BPM and SOA. Along with this comes event processing and next Business Intelligence. We walked into this scenario unwittingly with a client in UK and today it is hottest application of applied real time BI.

For one am enjoying the ride, but keep asking myself – what’s next?

Posted by Sohrab Kakalia at 04:07 AM | Permalink | Comments (0) | TrackBacks (0)

Being privy to multiple SOA projects in different continents and stages gives some interesting insights. Technology is hardly a problem, but it is always mentioned. With so many intelligent people around, I have reasonable confidence in stating that if a problem can be identified it can be solved.

So, what are some the real problems:

• SOA changes the basic definition of roles
• Funding of SOA projects today and chargeback models

 

SOA changes the basic definition of roles: Looking ahead 5-10 years, business analysts will morph into domain architects who can write WSDLs, look up services and orchestrate their own applications. Similarly application developers will become service or process developers. There will be infrastructure architects who don’t size the platform but the service. Similarly CIO/ CTO and Enterprise architect roles need to be base-lined and evolved.

What I am saying is that change management is a bigger piece of the SOA puzzle than technology. It is more important to address this if the organization wants to succeed. Many CIOs are hiding from this reality. Technology at this point is incidental.

Funding of SOA projects today and chargeback models: This by far is the most complicated statistical and mathematical adventure. The project funding model today in most US organizations is to have a “business case” for a business user who also sponsors this development. The development is then done by IT. These are, conventionally, silo applications with no intent of reuse. SOA breaks this basic funding process by its foundation on reuse. So how will funding happen in future? Consider these scenarios:

1. There is an urgent business need for compliance in an organization that has decided that all future development should be “SOA” oriented and must go through a-b-c steps to get started even if the business has funds to run it.
2. There is a corporate mandate that all new business requirements will be decomposed into a set of services which can be reused by other geographies, lines of business in the organization. Funding will come from the central pool (CIOs office for infrastructure) and Business CEOs/ VPs for their functional components.
3. Chargeback model: This will encourage spend in building and adopting SOA based services where a business unit that has the first need will need to fund the building of the service. After this, they can chargeback usage to other units utilizing this service. What determines the cost of the service? Internal revenue transfers will be a whole new paradigm. How will non-revenue services like Marketing, HR etc be able to pay for utilizing these services?

In one organization where point 3 above was implemented after considerable deliberation, there were no takers for almost 4 weeks. In week 5, there were multiple simultaneous requests to build services with dramatic urgency even though there was no apparent business need!

Digging in revealed that the business units had decided to “make money” on the chargeback model and were now cornering the most obvious useable service and had found deep pockets to fund it.

There are many similar areas that are not technical nor standards related, that need to be resolved through leadership, governance and simplicity.

Posted by Sohrab Kakalia at 06:05 AM | Permalink | Comments (0) | TrackBacks (0)