Native Apps At The Client & Cloud

Srinivasan Sundara Rajan

Subscribe to Srinivasan Sundara Rajan: eMailAlertsEmail Alerts
Get Srinivasan Sundara Rajan: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Cloud Computing, SaaS Journal, SOA & WOA Magazine, Microservices Journal


From SOA Abstraction to SaaS

New revenue-generating opportunities for enterprises

Service Oriented Architecture
Service-oriented architecture is the first attempt in aligning the IT with the business and this is now almost a default architecture for all the new applications created in today's enterprise. The definition of SOA emphasizes the following: service-oriented architectural style has the following distinctive feature - it's based on the design of the services, which mirror real-world business activities comprising the enterprise (or inter-enterprise) business processes.

Service Identification Approaches
While it is always easier to think about the new applications from the point of view of business and design them to represent the business view, but most enterprises in their journey to SOA have faced with the challenge of accommodating a huge set of legacy components and applications which are already developed over the years and are working fine for specific needs. This has made enterprises to adopt multiple approaches towards SOA.

Top Down Approach
This approach, as the name suggests, starts with the business processes of the enterprises and realizes them with the more fine-grained and lower-level functionalities. While this is an ideal approach, most times the underlying low-level components of a particular business process are complex enough and require an IT view rather than a pure business view for realizing the business process.

Bottom Up Approach
In this approach, while the enterprises wanted to view the service in alignment with how the business is actually realized, however, there are so many underlying IT components already in place that need to be reused in the best possible way, so that the enterprises can enable their IT processes toward SOA in a quickest possible time.

There is lot of material debating about whether to use a Top Down Approach or Bottom Up Approach or to use a combination. However, it is clear that most of today's enterprises have a long history of IT investment and over the years several legacy applications have been developed that automatically pave the way for Bottoms Up Approach.

SOA Abstraction Layers
From the above discussion it is clear that IT departments continue to view the low-level components at their level , while the businesses look at the IT services in alignment with how business work. This is achieved by abstracting the components from the lowest layer (i.e., at the legacy IT level) to the highest level (business view of the services). The following diagram presents view of SOA abstraction layers.

Legacy Object Integration Layer
As explained in the Bottom Up Approach at the lowest level of hierarchy, enterprises need to reuse their legacy and disparate applications and various adapters, connectors and other technologies needed here to connect with existing applications. These include connecting to custom built applications and proprietary databases.

Component Layer
Components are the realization of IT level functionalities that will ultimately use the legacy object integration layer. These functionalities exposed by components represent the building blocks of most services. For example components can be used to perform Database CRUD operations (Create, Read, Update and Delete) or specific utility functions.

Business Service Layer
This is the starting level where both the business and IT can understand how various individual steps of a larger business processes needs to be realized. For example in a typical Customer Order Creation use case, a individual service could be validating of address or check for duplicates of customer creation.

Business Process Service Layer
This is the highest level in the current enterprise SOA abstraction, where a entire business process is realized by orchestration of multiples business services to be of direct value to the business. This layer will be completely abstracted from IT so that business defines the kind of input and the output expected. However in the current scenario this layer is best suited for a single enterprise and within the boundaries of the enterprise.

Moving Beyond SOA to SaaS
While the above abstraction level for SOA has worked well for enterprises in the last few years and businesses started realizing the value of IT more than before. However the advent of Cloud Computing and Service Models like SaaS (Software As A Service) made the business process vendors as well as enterprises to think beyond a single enterprise but to multiple enterprises or take a global view.

While this is always no brainer for Business Process vendors to think beyond a single enterprise, this concept of enabling existing Business Processes beyond a single Enterprise has taken the interest of traditional enterprises also.

Because as the business models across the globe change and no body really can predict the directions enterprises take, some enterprises may venture into new markets while best providing the business knowledge they have built over the periods to their partners and expand in a collaborative way. Even some enterprises may totally take a path of selling their best grown software services to other enterprises and can make them as new revenue generating avenue.

Some of the examples could be:

  • An enterprise which has created a highly efficient supply chain process may provide that service to their partners in a totally new geography
  • An enterprise may provide the federal compliance services as a revenue generating mechanism

The following diagram extends the SOA Abstraction to the level of a SaaS service model, so that business processes go beyond a single enterprise across multiple enterprises and are truly extendable.

With the standardization of the Software as a Service model, enterprises stand to benefit from two angles"

  • Consume their non -strategic, non-core business processes from external providers thus making them concentrate on their core business.
  • At the same time, think beyond a single enterprise boundary for their core business processes and knowledge that is build over the years, which could either act as a new revenue-generating mechanism for the enterprise in this difficult economy or help them to partner with new players in new regions and expand their reach.

So thinking beyond enterprise SOA layers will not only benefit the Business Process as a Service vendors but even the large enterprises.

More Stories By Srinivasan Sundara Rajan

Highly passionate about utilizing Digital Technologies to enable next generation enterprise. Believes in enterprise transformation through the Natives (Cloud Native & Mobile Native).