Gandhi Sivakumar

Towards an architectural framework for service-oriented enterprises

Business enterprises today are increasingly being modeled as service-oriented enterprises (SOEs). That is, they are increasingly part of collaborations with other enterprises, with such collaborations being fulfilled by the exchange of business services among the participants. To that end, there is now a felt need for developing formal models of such collaborations, by leveraging past work on Enterprise Architecture (EA) models. In this paper, we present an architectural framework for modeling such collaborations as virtual enterprises (VEs), since these collaborations involve interactions among multiple enterprises. Our framework is modeled by treating the VE as an enterprise itself, but with special characteristics that distinguish it from regular enterprises, viz., nature of collaborations among the participating enterprises, extent of their participation, and conflicts among the participants. The latter characteristic arises due to the autonomy of the participants and the dynamic nature of inter-organizational business interactions, and is especially crucial for VE modeling. Throughout the paper, we illustrate our architectural framework with a realistic running example. We also present and discuss some future challenges regarding modeling dynamic behavior in the VE, in particular, conflict modeling & resolution among the participating enterprises.

SOI (Service Oriented Integration) and SIMM (Service Integration Maturity Model An Analysis

The constellation of SOA entities encompasses a triplet of Service consumer/provider and an optional registry. In the normal style, the service provider (“Service”) is instantiated and the details are stored in a registry. Service consumers seeking the required service explore the registry, locate the Service end points, receive the service contracts (normally as WSDLs), comply with the established contracts in order to consume the service. While this is an ideal scenario, in integration based environments the style differs where integration enablers as services are required to be built to aid integration. Thus Service Oriented integration (SOI) would mean the following depending on the type of players in the IT industry:• To an ISV (Independent Software Vendor) who develops products, SOI would mean exposing loosely coupled interfaces to be consumed easily by abstracting the implementation;• To a systems integrator, this would mean creating and hosting integration enablers as services( most of the times in the middleware layer) to be consumed by applications which in turn might fulfill the intended functionality by interacting with one or more back end applications. SIMM (Service Integration Maturity Model) defines a maturity model of such SOI based environments. This maturity model in turn will serve as an index to measure the level of flexibility and agility of an industry’s IT Environment to the changing needs of the business which is the key goal of SOA. Though there are many factors affecting SIMM, standards and modularity play a key role. In this paper we intend to analyze SIMM characteristics, benefits of standards combined with modularity, different enterprise environments and suggest the relevance of standards in each environment. In section I, we briefly discuss the functionality of integration enablers and various patterns. In Section II, we discuss the SIMM characteristics combined with modularity, explore in detail the various types of enterprises and requirements to comply with standards to achieve greater SIMM and finally conclude.

SATE--Service Boundary and Abstraction Threshold Estimation for Efficient Services Design

The key to successful adoption of SOA is not only reusability but also the ease with which services can be developed, deployed and maintained in a service providing environment. One key guiding principles of SOA is implementation abstraction, that fosters complete encapsulation of implementations, exposing only the primitives as interaction points with the service. Granularity of service abstractions defines the different level of primitives exposed to prospective service consumers. The primitives being the only external representation for a service, their design is extremely important as the granularity not only determines the ease with which the services are identified, but also the ease with which services realization can be achieved. So far there has been no systematic approach to apply design principles such that right level of abstractions can be defined. We present a tool called Service Abstraction Threshold Estimator (SATE). Given the available implementation artifacts, SATE allows varying levels of primitives to be defined, elicits the complexity associated with different levels of primitives and provides a threshold estimation engine that displays the optimal level of abstraction that can be achieved in a given service development environment. We demonstrate SATE on a real-world example, and also evaluate SATE against design decisions taken by software architects. The results of our evaluation show that SATE can provide more accurate threshold estimations, and also helps in reducing the time and effort taken to maintain already developed services.

Unravelling the Myth of big data and artificial intelligence in sustainable natural resource development

Natural Resources businesses span one or more of the following verticals: Explore & Discover, Develop, Extract & Transport, Market & Trade. Natural Gas (NG) is a key component of the Natural Resources industry, which contributes both directly and indirectly to sustain and support the day to day energy needs of humans. Various forums drive key initiatives to maintain the sustainability of natural resources for decades to come. The recent evolution of advanced Information Technology (IT) fields, termed as ‘Big Data and Artificial Intelligence (BD&AI),’ fortify these initiatives by providing anytime, anywhere access of data (for example in remote offshore assets or facilities) from a vast corpus base, in addition to enabling natural human interaction. In this paper we intend to explore the key primitives of BD&AI and cite the method of real-world implementation in the Natural Gas industry to further enable sustainable development.

SOI (Service Oriented Integration) and SIMM (Service Integration Maturity Model

The constellation of SOA entities encompasses a triplet of Service consumer/provider and an optional registry. In the normal style, the service provider (“Service”) is instantiated and the details are stored in a registry. Service consumers seeking the required service explore the registry, locate the Service end points, receive the service contracts (normally as WSDLs), comply with the established contracts in order to consume the service. While this is an ideal scenario, in integration based environments the style differs where integration enablers as services are required to be built to aid integration. Thus Service Oriented integration (SOI) would mean the following depending on the type of players in the IT industry:• To an ISV (Independent Software Vendor) who develops products, SOI would mean exposing loosely coupled interfaces to be consumed easily by abstracting the implementation;• To a systems integrator, this would mean creating and hosting integration enablers as services( most of the times in the middleware layer) to be consumed by applications which in turn might fulfill the intended functionality by interacting with one or more back end applications. SIMM (Service Integration Maturity Model) defines a maturity model of such SOI based environments. This maturity model in turn will serve as an index to measure the level of flexibility and agility of an industry’s IT Environment to the changing needs of the business which is the key goal of SOA. Though there are many factors affecting SIMM, standards and modularity play a key role. In this paper we intend to analyze SIMM characteristics, benefits of standards combined with modularity, different enterprise environments and suggest the relevance of standards in each environment. In section I, we briefly discuss the functionality of integration enablers and various patterns. In Section II, we discuss the SIMM characteristics combined with modularity, explore in detail the various types of enterprises and requirements to comply with standards to achieve greater SIMM and finally conclude.