"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.

« December 2006 | Main | February 2007 »

January 31, 2007

The new mantra in SOA Management

'SOA has created unexpected complexity' what caught my attention and reading through the article I hit upon another unexpected term -

‘The Ovum survey found a high correlation between a business' level of satisfaction with SOA and their commitment to managing IT as a set of services.’

Surprised! services being tagged with IT, services being abstracted to such a large extent (as my thoughts were channelized only on to SOA)... I continued reading and among examples was what I found - ITIL.  So it was about ITIL, a framework and set of best practices to be followed for IT management and operations. 

Interestingly both ITIL and SOA both happen to build on top of notion of services, but used in different contexts. 

Managing IT through a set of services - ITIL

Managing capability/functionality through a set of services - SOA

On a cautionary note this could bring some confusion about terminology (esp. 'service') if SOA management is being realized following ITIL processes and guidelines. Another good note about this is from ZapFlash.

A lot is being discussed on bonding and drawing parallels between ITIL and SOA (Link 1, Link 2, Link 3). In a recent conversation with Infosys experts, Ronald Schmelzer of ZapThink mentions -

"On one hand services developed under ITIL should be able to be represented in a Service Oriented manner, leveraging the abstraction, loose coupling, and composability capabilities of SOA for meeting ITIL needs."

Similar to ITIL, there other frameworks like ISO/IEC 17799, COSO, COBIT, NIST that defines necessary procedures and practices, of which we had explored the possibilities of using COBIT in one of our research papers (accepted at SCC 2005, need to have IEEE access).

Similar to ITIL the COBIT framework identifies broad management functioning areas (domains) like planning and organization, acquisition and implementation, delivery and support, monitoring etc. These domains are then mapped to processes and further identify control objectives for each of these processes.

Interestingly we are seeing more and more such standards, frameworks defined by conglomerated experts being agumented (if not really adopted but still discussed in detail) under the umbrella of adoption of services.

 

Posted by Naveen Kulkarni at 01:21 PM | | Comments (1) | TrackBacks (0)

January 18, 2007

SOA terminologies - defined !

The intended grand vision of a universal service broker though has fallen down; the need for cataloging service is however being more and more realized as critical pieces in solving the puzzle of realizing SOA. Till early last year there had been various products offering service-cataloging features based on UDDI standards.  But now we see another terminology being thrown across called repository. 

Continuing with my previous post in defining the terminologies, here are two more! 

Service Registry

A service registry is a searchable catalog or itemized list of meta-data on all the available services that are categorized or systematically arranged based on a predefined taxonomy.

Repository

A repository is a collection of information such as technical reference documents, reports, and policy descriptions etc. that is both current and historical about the service. This would typically be extending the data storing capabilities of the service registry and accessible with out any prior knowledge of the repository structure. Repositories are managed by the data provider and/or a registrar and are referenced in service registries through meta-data.

So putting it in simple statement registries are made of meta-data and repositories with data.  But what really makes up meta-data and data? In his tip Matsumura suggests that data and meta-data are determined based on the relationship. 

When referring to storing of data about services aren't we talking about managing content that is associated with service. Now there is another acronym that strikes - ECM.  What about the existing ECM solutions like Sharepoint portals, Lotus Notes, Hummingbird or FileNet (already in place) as few new products are contemplating on registry-repository solutions? Looks like the new products have opted to follow their own solution called service oriented content management or content management for service and not being dependent or adapted generic content management solution.  For instance, in one of the recent redbooks about WSRR says “WebSphere Service Registry and Repository is SOA and service centric in nature. It has not been designed to act as a generic content management solution and does not provide extended capabilities around information capturing, indexing or archiving.” In such cases there must be some thinking to be done both in physically hooking up ECM and repository and standard processes followed with ECM.

Posted by Naveen Kulkarni at 04:44 AM | | Comments (2) | TrackBacks (0)

January 16, 2007

Yet another attempt to define services!

SOA means different to different people as it can be applied in various degrees. This leads to various definitions or understandings among different communities like some listed by searchWebservice, webopedia. Various terminologies like service, service orientation, reusability of services, processes, registry, repository, service data objects, enterprise service bus, enterprise information integration, composite applications etc have made their way into SOA discussions.

However, least is bothered about the degree of understanding when such terminologies are used.  Standard bodies like OASIS are working on the creation of SOA blueprints one of the outcomes which is to arrive at an agreement on such terminologies.

Among all the terminologies the most important and very basic unit of SOA which is service, the definition of which is still unclear or not agreed upon. Apart from the standard bodies, there have been attempts to define what a service is in various groups and communities like SOA community, SOA yahoo groups, Wiki, blogs and glossaries (IBM, BEA).

Since SOA is bringing both business and technology community together and traditionally both communities have had an orthogonal way of thinking about the supporting of business by IT systems, having two definitions for services (as applicable for each community) rather than a common definition, would be an interesting attempt.

So here I give another shot at defining what a service is!

Definition for a Business Analyst

A service is a common activity which when applied under various contexts over different business entities results in a business circumstance that is uniquely distinguishable.

Definition for a Technologist

A service is a self contained, replaceable and reusable module that exhibits high cohesion of functional/semantic relatedness of activities and loosely coupled through multiple standard interfaces and bindings.

Posted by Naveen Kulkarni at 07:59 AM | | Comments (3) | TrackBacks (0)

January 09, 2007

SOA, BPM, Components, Objects proponent's views

Today I was reading a blog on zdnet about how SOA can be used and is being used in a non-IT world.

http://blogs.zdnet.com/service-oriented/?p=795

I have posted my repsonse on this blog as follows:

SOA proponents view the world as SOA fabric. BPM proponents tend to look at everything in terms of processes. The proponents of Compnents based design / OO tend to view the world made up of distinct objects / components. All of these views have its merits. We need to leverage SOA to see everything(discrete services) linked together through well defined interfaces and as JP pointed out remove the tight coupling between the service provider and consumer. Each of the services are made up of 1 or more business processes. The services are attached to objects or components. Once we get a clear picture of the merits of each of these school of thoughts it becoms easier to address a problem and provide an effective solution, be it a IT or non-IT scenario.

Posted by Shreyas J. Kamat at 07:37 PM | | Comments (1) | TrackBacks (0)

Service Analysis: Defining effective Service Oriented Architecture

The 3 prominent methods recommended for Service identification during the service analysis phase are -

 

1. Top down - Functional decomposition driven approach

 

2. Bottom up - Business process driven approach

 

3. Hybrid - Meet in the middle.

 

Unless it’s a brand new initiative, where there is no dependency on any of the existing IT assets, its very rare to see the Top down approach. The services end up being on the coarser side of granularity while adapting Top down approach and on the finer side of granularity while adapting the bottom up approach. If there is a common representation of the end state in Service analysis then the hybrid approach can be used effectively. However due to the lack of standards in representing services or service interaction diagrams, the end state does not conform to a common representation.

Grouping similar services into logical units of components in a bottom up approach or identifying components and then services in a top down approach is a very effective way and works very well in defining SOA based projects. Modeling all 4 architecture models business, application, technology and data coupled with Model Driven Architecture (MDA) helps in identifying the right business and technology components. In a bottom up approach grouping services in components after rationalization helps align with the business architecture. If you think through this thought you will realize that this is an effective combination of Enterprise Architecture framework with a Solution Architecture framework, resulting in a Service Oriented Architecture!

 

 

Posted by Shreyas J. Kamat at 04:50 AM | | Comments (0) | TrackBacks (0)

January 05, 2007

Quality considerations for services

Architecting services from an enterprise perspective does not just involve identifying and fitting pieces together, but managing and addressing cross cutting concerns or non functional requirements (NFRs). We see lot of discussion on SOA being around abstracting the business functions as reuse-able services.  But what is still tabooed are the quality attributes that have to be associated with services to make them truly enterprise class. 

To start considering about quality it would be a good idea to take a holistic view and apply ISO/IEC 9162-1 (and subsequent revisions) quality model to form the basis of defining quality requirements for service.  The four characteristics (Effectiveness, Productivity, Safety and Customer Satisfaction) of Quality-In-Use defined by the model needs to be much more appreciated for services that are envisioned to be adaptable and reusable. A good starting point could be work from ISO/IEC JTC1, Subcommittee SC 7, in developing ISO/IEC 25000 called SQuaRE which provides requirements specification, planning, management, measurement and evaluation.  Also the work from SEI can be looked for understanding engineering methods which takes the view of gathering the quality requirements based on various stakeholders needs.  These can help developing specific quality models for the services.

More over, with quality models to translate and derive quality requirements for services the obligation is on the IT architects to additionally worry about the existing system qualities. So, a flat view over services has to be complimented with an approach of looking into quality (both borrowed from existing systems and new)right at the initial stages of concpetualizing. This adds a new dimension of complexity during the adoption of SOA. Our thought and work in this area are being presented as tutorial at WICSA 2007.

Posted by Naveen Kulkarni at 04:46 AM | | Comments (0) | TrackBacks (0)

January 04, 2007

Introducing information/data service expert: Rajeev Nayar

I am excited to introduce Rajeev Nayar, who will be enlighting us with his knowledge/experience in the information/data services and intergation area. Rajeev is a Principal Architect working with Infosys and brings a wealth of experience in applying SOA in the data integration/consolidation areas. Recently he has worked on a coule of large engagements for a Financial Fortune 100 company in USA, where he defined the SOA strategy and architecture. Welcome Rajeev and Happy blogging!

Posted by Shreyas J. Kamat at 06:55 PM | | Comments (0) | TrackBacks (0)

SOA: Top Down, Bottom Up or Hybrid?

Conventional wisdom suggests that to achieve strategic approach to SOA, it is ideal that business centric nature of the Services be the guide to designing SOA.

 But the dichotomy of SOA realization is that services are realized  from existing systems, hence it necessarily mandates a role for bottom up approach to leverage legacy and EIS systems.

So it is top-down or bottom-up for SOA?

Meeting the best of both worlds from both top-down and bottom-up approaches are ideal to achieve the right balance, and right level of prescription for SOA deployment in enterprises.

 

One approach we suggest is Meet-in-the middle. Let business services be designed top-down.

Let realization of fine grained services be done bottom up from existing systems or new development.

Let there be a MEET-In-The-Middle approach via service impedence rationalization between the top-down and bottom-up approaches as the ideal panacea. A detailed analysis can be found at the paper titled :An Architectural Framework for Service Definition and Realization, presented at SCC 2006 . details at http://doi.ieeecomputersociety.org/10.1109/SCC.2006.97 

 

Posted by Dr. Srinivas Padmanabhuni at 10:54 AM | | Comments (1) | TrackBacks (0)