Service Modeling and Design - Executing SOA book

I am excited to introduce the latest SOA book in the market entitled "Executing SOA - A Practical Guide for the Service Oriented Architect". The book is available for pre-order from Amazon at http://www.amazon.com/Executing-SOA-Practical-Service-Oriented-Architect/dp/0132353741/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1209173802&sr=8-1 and also from other book store sites. It is going to be in the stores by late May this year!

Being a co-author of this fascinating book gives me a sense of pride and a feeling of satisfaction of having addressed certain burning topics in SOA. There is a ton of work out there that talks about various theories around SOA but the problem arises when the rubber hits the road; when the SOA architect is called upon to execute on an actual real-world SOA engagement. This book is meant to address the practical needs of an architect to execute successfully on an SOA engagement.

One of the chapter addresses SOA modeling and design in a very precise and prescriptive technique that provides ample guidance to the SOA architect to develop an architecture and execute on the same. It introduces the RUP-SOMA method from IBM which has now tasted implementation success in hundreds of real-world projects all over the world. The technique has its roots in three major phases - sevice identification, service specification and service realization. Each phase is dealt in minute details to the point that one can even develop a project plan on executing a SOA engagement from an architecture, design and implementation standpoint.

Let me know if you would like to get a sneak peek on this methodology and I would be happy to blog it with you!

SOA EDA Conundrum - Loosely coupled and decoupled architectures

There is a common misconception between loosely coupled and decoupled architectures. In fact the misconception is such that people use the two concepts interchangeably.
A loosely coupled architecture is one that is evident in the foundation principles of SOA. Based on the degree of coupling a service consumer may:

• Directly invoke the service producer by knowing the service URL a-priori
• Only know about a presence of virtualized service which in turn has the intelligence to route the consumer request to the most pertinent service that may fulfil the request
• Only know directly about the presence of a registry

In SOA the service consumer and the service producer is loosely coupled but there remains an element of coupling between them the degree of which is based on the chosen architecture.

A decoupled architecture is one in which the emitter of a business event has absolutely no knowledge of the potential receiver(s) of the event and what a receiver may do with the event. This is the principle behind EDA. EDA hence is tailor made for asynchronous communication but that is not to say that a synchronous communication is not possible using EDA.

In fact just like you can use SOA for asynchronous communications between the service consumer and the provider you can also use EDA for synchronous and well-defined, predictable communications between the event source and the recipients.

SOA and EDA can certainly coexist and that too in a very compliementary manner. Using both in a hybrid architecture can realize the real-world business requirements wherein both synchronous and asynchronous communications may possibly be required to realize complex requirements.

It is our responsibility as architects and thought leaders to come up with prescriptive architectures and guidance around how to develop a hybrid architecture based on SOA and EDA principles.

Creating an Enterprise Service in SAP is diffferent from creating a Composite Application

There has been some confusion around the mechanism and methodology to create Enterprise Services vis-a-vis the development of Composite Applications in SAP.
The identification, development and certification of enterprise services follow a strict internal governance mechanism inside SAP. Enterprise Services are proposed either by the business application suite groups (e.g. SCM, SRM, CRM) inside SAP or by a member of the SAP IVN (Industry Value Network). Enterprise Service definition is a top-down approach, one in which a service is defined in relevance to a business functionality that it tries to solve. It has the much needed business alignment that business-level services ought to provide. Enterprise Services are defined in SAP XI. The message structure are defined first. The message interface is defined by using the definitions of the message structures. A message interface is exposed as a service which is then developed using NWDS and XI and then provisioned into the Enterprise Service Repository (ESR).
Composite applications on the other hand are developed more or less based on a bottom up approach. A composite is created using the CAF-Core and CAF-GP tools of the Netweaver platform. The UI elements are developed either in WebDynPro or Visual Composer. The CAF-Core uses services that are either defined in the ESR or it can create services based on the various back-end systems e.g. CRM, ERP which expose their IT functionality through BAPI's. CAF-Core defines two types of services: Entity Services (encapsulate the business objects from the back-end system) and Application Services (which combine entity services, add business logic on top of them and are exposed to be consumed by the elements of CAF-GP, WebDynPro and Visual Composer). CAF-GP is a mechanism to simulate the creation of business processes through the use of constructs like Actions, Blocks, Processes and Callable Objects. The Callable Objects are used to invoke the Application Services in CAF-Core. Processes at the CAF-GP are subsequently deployed and invoked through the SAP Netweaver Portal.

Hence, there is an essential difference in methodology in SAP between defining and developing Enterprise Services and developing Composite Applications.

I would be really interested to see some more light shed on this topic.

Service Granularity Challenge with SAP's ESA

SAP uses its Netweaver based development infrastructure to define services in a SOA.
The business services are defined in Netweaver Developer Studio (NWDS) which is also known as the CAF (Composite Application Framework) Core. They have three main constructs namely an external service, an entity service and an application service.
An external service allows for the linkage to services defined outside the CAF Core environment sandbox.
An entity service essentially models an operation on a business object (BO) as a service. Typically these map to existing BAPI's that work on business objects that are stored in the SAP Business Warehouse (BW). Operations on business objects being used as a basis to define services, to me, is a very parochial approach to service definition and often becomes too fine grained to follow the footsteps of a service-proliferation-syndrome.
Application Services are defined as coarser-grained services that combine or use multiple entity services with some applied business logic to tie them together. Even here, it is more of a bottom up approach to service definition. I fear that, using this approach, we are missing the key issue of aligning services to business processes. The concept of business aligned services seems to be lost in the mechanism, somewhere !!!
There is another tool, more of a somewhere-inbetween-a design-and-a-runtime mechanism to define orchestrations of services, based on the SAP Guided Procedures (GP). GP has concepts of actions, blocks and callable objects. Actions and blocks can be simulated as a composition of services together - ala service composition. But then, these service composites, are not pushed down to the business service layer - which to me is an issue.

I would love to hear some comments on this.

Metadata repository integration conundrum

There is a lot of hype and buzz over metadata repository and management.
The main concern or rather an imperative requirement that is becoming commonplace is to come up with a strategy for implementing a centralized metadata repository solution that integrates the enterprise-wide business and technology metadata through a consistent and standard format.

For companies that are trying to develop such a metadata integration strategy and implementation, the most common solution is to partner with or buy a metadata repository solution that is capable of realizing the metadata integration dream.

But unfortunately enough, various efforts to logically or physically consolidate metadata descriptions into a single, shared and common view is met with the real-world issues of semantic inconsistencies and differences that exist both at the business as well as the technology level. These differences makes it hard if not practically impossible to find a common ground for metadata integration through a repository consolidation.

The Business semantic inconsistencies mainly arise from the lack of metadata management policies, procedures and standards that are implemented across the various Lines of Business (LOB's). This is further aggravated by a lack of ownership of the policies and standards by LOB owners and hence the reusability of metadata information is seriously thwarted.

The Technology semantic inconsistencies are easier to understand and comprehend. The varied array of technologies e.g. databases, datawarehouses, application servers, business process modeling techniques, business intelligence, etc which are further augmented by the ever-increasing number of vendors offering products and solutions, makes it a real tall order to standardize on an all-technology-encompassing standard for metadata integration.
Althogh efforts have been made by Standards bodies e.g. OMG to standardize on an information model for metadata exchange like XMI, it is almost an impossible chase towards attending technology standardization for metadata integration. Consider the commonplace occurrence of competitive vendors trying to provide differentiating solutions through proprietary extensions of the standards and specifications. This alone makes the dream of achieving a semantic consistency between metadata for technologies, impossible to realize.