Recommended Approaches to Service-Oriented Architecture

by Yogish Pai
10/11/2005

The Time

It is the best of times, it is the worst of times, it is the time of service-oriented architecture (SOA), it is a time of traditional development methodologies, it is a time when products have matured, it is a time when products don't exist yet, it is the season of the optimist, it is the season of pessimist. We have endless possibilities in front of us, but we are concerned about being irrelevant. We are going to achieve the state of nirvana, we are going directly the other way—in short, this is a huge opportunity for IT to demonstrate its true value.

It is the year 2005, and most IT executives agree that the following market conditions are forcing both business and IT to transform the way they do business:

• Globalization is resulting in businesses having to be agile just to survive.
• Tighter economies are creating consolidations because even though enterprises have large cash reserves, market growth is anemic.
• Business process outsourcing is here to stay and expected to grow exponentially.

IT Systems Today

Traditionally, IT has been taking orders from business owners, resulting in IT strategies that are application or integration focused. In addition, governance and funding models have pushed both business and IT stakeholders to do whatever it takes to meet a particular business unit or department need. This approach has resulted in IT deploying multiple systems that performed the same tasks within an enterprise or business unit. The duplication is manifested in infrastructure services such as authentication, single sign-on, and data marts, as well as applications (packaged and custom), such as sales force automation (SFA), quoting, and order management. One can only imagine the complexity of attempting to make modifications to this portfolio that reflect a change in business process or accommodate an acquisition.

In the best cases, as each business unit or department implemented its own solution, IT teams integrated the systems using a point-to-point or EAI approach that connected the application to both up-stream and down-stream systems. To track the transactions across the business process, they propagated some key values across the applications—although inconsistently—and created multiple operational data stores (one for each business unit) to track key performance indicators.

To provide a seamless user experience, IT organizations, at the request of business owners, built portal applications to connect to multiple backend applications, data marts, and master data. While effective from an architectural standpoint, this best case solution is extremely complex and expensive to maintain, particularly as enterprises are under pressure to increase revenue, while reducing costs.

The Future Vision

Revenues, costs, and implementations aside, most business and IT executives agree on one fundamental business principle: Their business processes differentiate them from their competition. For some, it may be the way they handle their supply chain, for others, it may be their ability to bring new, innovative products to market.

Figure 1.

However, the approach to obtaining that competitive process advantage often varies considerably among members of the business and IT operations teams. For example, some business operations teams prefer to demonstrate quick wins to validate an approach, while IT operations teams prefer to build out the infrastructure. For both teams, the right answer is likely an SOA approach.

Figure 2.

The SOA Approach

SOA is the business operations strategy for leveraging information to meet their objectives, such as increasing overall revenue, increasing customer satisfaction, and improving product quality. Both business and IT stakeholders need to partner to define the strategy and the roadmap to achieve stated objectives.

The following is recommended approach. based on experience, for developing an SOA roadmap:

• Develop an information strategy that identifies key performance metrics.
• Develop an SOA Blueprint that includes business principles, reference architecture, roadmap, governance and organization, business benefits, etc.
• Identify "quick wins" to demonstrate the business benefits of adopting SOA.

Adopting SOA requires IT organizations to identify the services infrastructure required to deliver business solutions. It is important to demonstrate "quick wins" to the business to show value and keep them engaged. As the services infrastructure is based on the SOA principles of coarse-grained, loosely coupled, and standards-bases services, it enables IT to be proactive. It provides IT with the ability to be responsive to the changing business needs by providing them with global solutions, with reduced application and infrastructure complexity, increased reuse of business services, and service orchestration capabilities. In short, this approach enables IT organizations to meet the market challenges by transforming itself along with the business.

Figure 3. Blue: Business Solutions, Red: Services Infrastructure, Grey: Business Processes

The above diagram represents both business solutions and the services infrastructure required to provide these solutions. The best practice is to develop the services infrastructure on an as required basis. It is important that the activity of mapping the services infrastructure is performed while developing the SOA roadmap, especially as this mapping enables IT to show the benefits of reuse, as well as demonstrate the agility for developing new or modifying existing business solutions. The following examples illustrate how one could map business solutions to services infrastructure to solve today's typical business challenges.

Summary

Adopting SOA can be difficult for both business and IT executives. To get started, this requires IT organizations to identify the services infrastructure required to deliver business solutions. It is important to demonstrate "quick wins" to the business to show value and keep them engaged. As the services infrastructure is based on the SOA principles of coarse-grained, loosely coupled, and standards-bases services, it enables IT to be proactive. It provides IT with the ability to be responsive to the changing business needs by providing them global solutions, reduced application and infrastructure complexity, increased reuse of business services, and service orchestration capabilities. In short, this approach enables IT organizations to meet market challenges by transforming themselves along with the business.

References

• dev2dev SOA Technology Center
• BEA SOA Resource Center
• Arch2Arch Resource Center
• SOA Blueprints project
• Disparate Service Invocation Challenges and Solution Alternatives for SOA in J2EE by Sushil Shukla and Sudhir Bhojwani (dev2dev, February 2005)
• The Enterprise Service Bus: Building Enterprise SOA by Fausto Ibarra (dev2dev, December 2004)
• The Implications of a Service-Oriented Architecture (SOA) on Security - dev2dev webinar, September 2005
• A Practical Explanation and Example of SOA for the Non-Techie - Eric Stahl's blog (dev2dev, August 2005)

Yogish Pai is the Chief Technology Officer (CTO) of IT, at BEA Systems, Inc. Yogish has over 18 years of experience in delivering business capabilities for large enterprises. At BEA, Yogish is responsible the enterprise architecture team and has been providing thought leadership through the various phases of adopting SOA within BEA-IT.

Return to dev2dev.

Showing messages 1 through 2 of 2.

• Comments Regarding Article SOA
  2005-10-26 01:03:06 oany_81 [Reply | View]
  
  Mr Yogish Pai,
  The article was a cool one.

• Trackback from Editor's Blog
  Architecture is important
  2005-10-12 07:17:49  [Reply | View]
  
  The importance of architecture; Articles on 'Recommended Approaches to Service-Oriented Architecture' and 'Demystifying Security Standards.'