Defining business services: SOA from a corporate perspective

While SOA has been widely adopted, several organizations have yet to fully understand how it can be fully leveraged to truly bridge the gap between business and IT. From a business perspective, the focus has always been on maximizing value for the organization. To accomplish this, the organization relies on IT to strategically automate business operations. However, the ultimate success of this relationship often comes down to how an IT environment is designed, staffed, and what resources are available to it. Furthermore, the actual culture of an IT department can play an important part in determining just how in synch it is (or wants to be) with the business side.

The fall of the former AT&T Wireless is a recent reminder as to how destructive a gap between IT and business can really be. A sharp increase in customer-related issues due to the glitches in the CRM implementation brought this cell phone service leader into a rapid decline. It is common in the business community for there to be a sense of helplessness when technologies and IT projects seem like distant, disconnected initiatives. Many times, the business has no choice but to submit to a path dictated by IT.

Though significant progress has been made through many innovative technologies and evolutionary methodologies, this business-IT gap still exists today. Service-oriented architecture as part of service-oriented computing represents a sincere effort on the part of the technology community to offer a framework capable of conquering this gap. While successes have been reported, SOA adoption projects are, for the most part, still in the early stages. Much more work is ahead to for us to fully witness the strategic benefits to be had by this platform. I very much believe that SOA's business-driven vision will prevail and that all of the associated benefits (such as increased agility, cost containment and measurability) are there for the taking as part of a well-merged business-IT platea

To continue reading for free, register below or login

Requires Membership to View

To read more you must become a member of SearchSOA.com

At the beginning of 2003 Gartner reported that SOA will become the dominant enterprise architecture solution of the foreseeable future. Indisputably, the concept of service-orientation and its associated architectural paradigm have been widely accepted and adopted over the past four years.

In 2006, Ovum surveyed 333 US IT decision-makers and found that 27 percent of large enterprises and 17 percent of medium-sized companies have SOA operationally deployed in at least some areas of the IT infrastructure. Compared to previous architectural paradigms such as CORBA (which never really seemed to gain widespread momentum) and EAI/BPM (which gained limited success within the past seven years), SOA is the clear winner of any enterprise paradigm that has been proposed to this day.

Many SOA professionals and SOA platform vendors have formulated numerous explanations as well as marketing pitches for this phenomenon. I consider it all due to a simple reason – the magic word of "service". A service is self-explanatory and brings with it a connotation that naturally leads to visions of increasing business value. One would expect an architectural model and platform based on this fundamental concept to establish an environment that will better support the business.

There are several reasons for the existence of the business-IT gap. Firstly, from a business professional's perspective, IT professionals speak a different language and think in a different frame of reference. More often than not, business professionals give up the leadership in driving the business goals and hand the reigns over to the IT folks.

A common consequence is the creation of disposable application silos no one bothers to change or applications that are awkwardly extended into integration architectures. As the quantity of silo-based applications increases, the drain of IT on the organization increases also. Subsequent business initiatives lose credibility because no one believes they will actually provide a justifiable return on investment. This can lead to a lack of agility and flexibility, mounting operational costs and an overall loss of trust and confidence in IT. All of these factors hinder IT's ability to carry out (and receive support for) new initiatives.

Secondly, from the IT professional's perspective, the business side tends to propose unrealistic requirements that currently available technologies cannot meet or which demand too much change to existing legacy applications. In other cases IT believes it is not given enough time or budget to fulfill the requirements it is being asked to automate. IT professionals are also overwhelmed by the constant emergence of new methodologies, technologies, vendor products and upgrades, and concerns about vendor lock-up, technology lock-up and skill shortages.

It now appears as though both business and IT communities are hoping that SOA will bail them out of this messy reality. Are current-day SOA platforms up to this challenge? Let's explore some common challenges to achieving this goal.

SOA platform vendors continue to focus on technology-centric messaging. On the other hand, large system integrators leverage their combined business and technology strengths to promote business-centric approaches. As a result, the adoption of and approaches to SOA have been widely different from company to company and project to project.

Some confine themselves to the application scope only to make the ongoing application development comply with the SOA architectural model. Others believe SOA should be applied to their integration projects, connecting backend applications and enabling process automation and management. A few even find its use as part of business process improvement.

Those who believe SOA is the panacea have already planned enterprise-wide adoption and governance, while hesitators inch their way through departmental pilot projects. The current situation is reminiscent of the six blind men describing the elephant. Amongst them, everyone believes the shape of the elephant based only on the portion of the elephant they touch.

When you qualify a set of services as "common" or "business," there are many aspects to be considered, including usage communities, governance policies, performance monitoring, change management, reusability, existing protocols, design standards, and, of course, the organization's unique business architecture. A business service in one environment may be something completely different in another.

Since SOA's essence is to organize and open up functions of any kind as services for sharing within and across an enterprise, an IT ecosystem's complexity inevitably grows in both perceived and real senses.

It is perceived more complex because SOA technology and practice are still in their infancy, but already possess more substance than most previous platforms. Hence, IT professionals are in the climbing edge of the learning curve.

The complexity is also real because of the increased granularity of services and capabilities and the increased agility for composing something new and publishing it in a short timeframe with less people involved. These and other distinct characteristics of service-oriented solutions can open up a Pandora's box that requires a new generation of IT infrastructure management tools.

From a business professional's perspective, complexity is inversely proportional to the chance of success for any IT initiative, but proportional to the cost of total ownership. Therefore, complexity in relation to SOA is something that needs to be understood and planned for in advance. That way, the organization takes control over the adoption of SOA and all of the technology and business-related issues and impacts that come with it.

In addition to the added complexity, business professionals are also concerned about the real value of implementing SOA. Although SOA evangelists have been promising business professionals that this time reusability will be achieved because every vendor seems to have reached a consensus on adopting Web services, the truth is that no one can guarantee that vendors will not hide their own "advanced proprietary features" to gain a competitive advantage, or that there will be no new innovations in the next decade that will annul or out-smart the current ones.

The IT community has to convince the business community that this time around IT is not using SOA as another excuse to redevelop the same old functions under a new guise. There needs to be a common understanding and education for both IT and business people, so that each appreciates and truly comprehends what SOA and service-orientation are all about. With a common understanding, both communities can work together to leverage this platform in order to finally close the business-IT gap.

These three challenges can hinder the scale and speed of SOA adoption and prevent the potential of SOA to positively impact the business. The proposed solution for sealing the business-IT gap is to "let the business focus only on conducting business and nothing else." In support of this goal, business services need to be designed with flexibility and adaptability in mind.

Depending on who you are and how an SOA transition may affect you, SOA itself can be viewed with varying perspectives. If SOA is misunderstood and misguided at the management-level, the gap between business and IT will only be widened. So, it is vital to understand what it needs from IT, and why adopting SOA can expedite the fulfillment of business needs.

The essence of most businesses is to grow enterprise assets and raise the value of the organization as a whole. Value can be measured by profitability, revenue and profit growth. SOA positions solution logic as services and services are very much IT assets. More is invested in them and more return is expected from them. Therefore, in order to understand how to overcome the aforementioned challenges to adopting SOA, we first need to fully appreciate what constitutes an IT asset.

Wikipedia defines the asset as the "economic resources controlled by an entity as a result of past transactions or events and from which future economic benefits may be obtained." However, with asset management comes the inevitable issue of liability. Wikipedia further states that liability is "a present obligation of the enterprise arising from past events, the settlement of which is expected to result in an outflow from the enterprise of resources embodying economic benefits."

An organization may or may not have control of the time, terms and conditions upon which a liability is settled. Thus the liability becomes a risk as well as an opportunity before the risk occurs. So the first line of defense in our pursuit of IT-to-business alignment relates to the management of high-risk liabilities.

How is this discussion of assets and liabilities relevant to SOA? The logical strategy when operating a company is to grow assets while minimizing risks. SOA and service-orientation establish a technology paradigm capable of enabling this strategy and business services play a key role.

One of the most important assets for an organization is the product it provides to customers or users. A product is any object that can be sold or traded for profit. A service can be viewed as special type of internal product. Let's discuss some principles for defining services.

Figure 2: A business is all about providing services to potentially liable external entities.

Once we understand that the foundation of a business is built on its assets, we are ready to deal with the three SOA adoption challenges listed previously.

There are eight established principles for services from a design perspective. These are standardized service contracts, service loose coupling, service abstraction, service reusability, service autonomy, service statelessness, service discoverability and service composability.

Although Thomas Erl's principles are intended for IT professionals who are involved in implementing SOA projects, some do apply at the business level. The standardized service contract principle, for example, can be used by business and IT groups as the basis for defining business requirements as contracts between their respective communities.

A business service can automate an activity or provide a function designed on behalf of the organization. Note that the recipients of corporate business services are mostly related to the liability part of the assets. For example, through the use of business services, customers of a retail store pay money in exchange for products, users of a bank deposit money into banks in exchange for checking account convenience, employees of a manufacturer offer "time and skills" products in order to get paid, suppliers of a telecommunication service provider ship network equipments and receive payment, investors issue credit in exchange with interests and dividends, and regulators monitor the regulatory compliance and get paid in the form of tax or dues.

To be more specific, examples of business services are quite common in the corporate life:

Once business services are defined, they become the contract between the corporation and IT for IT to automate the manual service functions or reuse functions that are already automated. Erl's service design principles such as service abstraction and service reusability can be applied when the business and IT begin to finalize IT project requirements and embark on service-oriented analysis and service modeling processes.

Behind each corporate business service there is an internal business process or procedure that drives the delivery of the service to the recipient. There are two ways to trigger a business process: by a request-for-service message from a service recipient or via internal channels, such as a timed event. When dealing with an organizational service recipient, there might be a cross institution protocol that guides both parties to complete transactions step-by-step. Compliance to that protocol is also built into the internal business process for the relevant business service.

Figure 4: Business services interact with recipients while the business processes drive the service delivery.

The key point is that the enterprise offers a catalog of business services that accurately express its business intelligence. A shift introduced by the adoption of SOA is that, from a value perspective, the enterprise now focuses on business services and not on business processes.

This runs contrary to the common belief that an organization should be business process driven. Most small to medium companies care less about processes, but cannot live without well-defined services, whereas larger organizations may need to adjust to this new priority.

Of course, standardizing, streamlining, automating and continually improving the business processes will empower the business to scale with great efficiency, competency and agility. However, in the end, it is the services that automate the processes.

Now that organizations need to focus more on how to provide better business services, they surely do not want to see their IT departments become roadblocks to delivering those business services in a timely manner.

1. Business services and business processes be mandatory elements of the business with or without the support of the IT.

2. Business services and business processes be operated and maintained with minimal effort so that they can be repeatedly reused and recomposed in support of new business requirements.

3. Even when silo-based applications are considered desirable there must be support to continue building and reusing existing business services. That is how IT will eventually be able to fully align itself behind the business goals and direction.

There are four professional branches that are typically positioned around business services and business processes:

Figure 5: Business services and processes surrounded by the four common professional branches.

From the business professional's perspective, the business service operational environment is vastly simplified since they no longer need to worry about the details of the IT projects. Their working environment is now mostly self-contained. However, in reality, the IT department is still very much engaged in creating and maintaining this platform.

Because SOA promotes that solutions expose themselves as services, technical interfaces used to access services can be aggressively standardized and therefore potentially be made easy to interact with. The orchestration of standardized business services therefore becomes a constant option as we are able to change the configuration in which the services can be combined in support of new and changing requirements.

Business process management vendors are also developing new generations of SOA-based BPM products that target business professionals. This will further ease the utilization of business services, as the technical skillset requirements for orchestration tools will decline. Essentially, a non-technical business analyst will be able to assemble services together by defining traditional workflow logic.

These innovations lead the notion of organizational agility, a key strategic benefit that has always been linked to SOA and service-oriented computing.

1. Shorter time-to-market - Because it is now easier to create and combine business services, the enterprise can maneuver its way through its market without being held back by lengthy IT implementation cycles.

2. Focused business performance monitoring - Business services-related metrics tie into the corporation's overall KPIs. This will be of interest to enterprise executives that pay attention to performance metrics, such as inflow or outflow of cashes between the corporation and business service recipients, customer churn ratio, employ attrition ratio, regulatory compliance delays, etc.

3. Constant fine-tuning and swift strategy change - By constantly monitoring KPI data generated by business services, strategists and executives can work together to regularly reassess an organization's status and perhaps make timely changes to stay more competitive.

4. Smoother merger and acquisition - Instead of IT departments scrambling to figure out how to work together subsequent to a merger or acquisition, merged companies can leverage business services to consolidate disparate enterprise applications and resources.

Furthermore, a service-oriented corporation can better ensure business continuity through knowledge management and minimal reliance and dependence on IT professionals. It can also raise IT productivity by having IT staff more focused on how to support business services through required infrastructures and frameworks.

Business-centric services provide a very real medium by which IT can be fully aligned in support of the business. However, having business services defined and managed is not enough for an enterprise to start rolling out enterprise-wide SOA frameworks and infrastructures.

Principles have yet to be established to accommodate and govern the delivery, operation and evolution of business services. Part two of this article series will extend the discussion to tackle issues like channels for providing business services, business processes for executing business services, operational business services, processes for supporting business processes and, most importantly, role-based organizations.

Please note that this article is purely based on the author's personal research. It is neither associated in any way with nor sponsored by Google. The information and statements contained in this article are collected from public sources and merely reflect the author's personal choices and opinions. Mr. Walter Blaschuk of BearingPoint reviewed this article and contributed valuable comments.

This article was originally published in The SOA Magazine The SOA Magazine, a publication officially associated with "The Prentice Hall Service-Oriented Computing Series from Thomas Erl" . Copyright © 2007 SOA Systems Inc..


	Home > SOA Tips > Guest Commentary > Defining business services: SOA from a corporate perspective