Service Oriented Architecture SOA Explained - Seven Steps

Service Oriented Architecture SOA Explained - Seven Steps

This page looks at some definitions of Service Oriented Architecture SOA and describes the steps an organization must take before it can be truly successful in realizing the cost and agility benefits offered by enterprise service-oriented architecture. It discusses the various stages of Service Oriented Architecture SOA adoption describing the technologies, processes, and best-practices available to help companies succeed in their Service Oriented Architecture SOA initiatives.

The 7 steps to Service Oriented Architecture SOA are:

1. Create/Expose Services
2. Register Services
3. Secure Services
4. Manage (monitor) Services
5. Mediate and Virtualize Services
6. Govern the SOA
7. Integrate Services (ESB)

Steps 2 through 6 describe cross-enterprise concerns that should be addressed with a centralized SOA infrastructure platform. Steps 1 and 7 address specific needs and are often delivered as part of an existing enterprise application stack. Following these steps will lead an organization down the right path to realizing the benefits of SOA Service Oriented Architecture.

Wikipedia defines SOA as follows:

In computing, the term Service-Oriented Architecture (SOA [pronounced “es-ō-ā"]) expresses a perspective of software architecture that defines the use of services to support the requirements of software users. In an SOA environment, resources on a network[1] are made available as independent services that can be accessed without knowledge of their underlying platform implementation[1]

Service Oriented Architecture was first proposed by Gartner analysts Roy W. Schulte and Yefim V. Natis. They specified Service Oriented Architecture SOA as “a style of multitier computing that helps organizations share logic and data among multiple applications and usage modes.” [2]

Service Oriented Architecture SOA is usually based on Web services standards (e.g., using SOAP or REST) that have gained broad industry acceptance. These standards (also referred to as Web service specifications) also provide greater interoperability and some protection from lock-in to proprietary vendor software. However, one can implement SOA using any service-based technology.

This provides a concise and accurate definition of Service Oriented Architecture SOA, but it does not describe the reasons why an organization would want to move towards an SOA, or the benefits such architecture can offer. The value and core tenets of SOA are described well in business terms in the book Understanding Enterprise SOA, by Eric Pulier and Hugh Taylor of SOA Software.

Also from Wikipedia’s definition of Service Oriented Architecture SOA:

Enterprise architects believe that Service Oriented Architecture SOA can help businesses respond more quickly and cost-effectively to the changing market conditions[3] . This style of architecture promotes reuse at the macro (service) level rather than micro levels (eg. Objects). It can also simplify interconnection to and usage of existing IT (legacy) assets.

In some respects, Service Oriented Architecture SOA can be considered an evolution in architecture, not a revolution. It captures many of best practices or actual use of the architectures that came before it. In communications systems, for example, there has been little development in recent years of solutions that use truly static bindings to talk to other equipment in the network, but by formally embracing an SOA approach, solutions are better positioned to stress the importance of well-defined, highly interoperable interfaces. This should greatly decrease integration costs and allow for much more dynamic solutions to be deployed.

Drilling into these concepts we can see that there is a set of basic capabilities that are required to achieve the potential benefits of Service Oriented Architecture SOA. Wikipedia discusses a number of these guiding principals, amongst which are:

• Reuse – the ability to encapsulate and expose coarse grained business functions as services
• Loose-coupling – ensuring that service consumers are sufficiently abstracted from the physical implementation of a service
• Identification and categorization (discoverability) – making sure that potential consumers can find the services they need

These fundamental principals lead to a natural order of activities an organization

How to Build an SOA Roadmap

How to Build an SOA Roadmap

There are four phases to developing your SOA roadmap: SOA Planning, SOA Maturity Assessment, SOA Future Vision, and SOA Roadmap Definition.

SOA planning
During this phase, your SOA initiative is organized and defined. Stakeholders are brought into the process through communications and briefings, and mutually agreed upon priorities and parameters are set. Because this phase involves employees across your organization, clear and ample communication is critical. During this phase you will:

Define the scope of SOA.
Establish boundaries and alignments with other IT initiatives.
Appropriately showcase the business justification for SOA.
Show alignment of existing and future business initiatives.

SOA maturity assessment
During the SOA maturity assessment phase, you will establish a metric for where you are today. Here you will define what services and capabilities you currently have that can serve as a starting point for SOA, as well as identify projects that may serve as foundation projects. Through a series of interviews and questionnaires, your teams should examine the various domains—analyzing, base-lining, and validating the "as-is" current situation for each. Use BEA's Domain Model to structure your examination of the following:

Business Strategy and Process: Top-down view of business strategies and processes.
Architecture: Review of current architectures, policies, and standards.
Cost and Benefits: Overview of existing cost structures and benefits cases.
Building Blocks: Analysis of existing services, processes, tools, and technologies.
Projects and Applications: Review of existing systems, and in-flight and planned projects.
Organization and Governance: Analysis of existing governance structures and policies.

SOA future vision
In this phase, teams use workshops to determine and define the desired "should-be" state and ensure cross-organizational buy-in.

Business Strategy and Process: Correlation of SOA future vision with business strategies and processes.
Architecture: Guiding principles, requirements, policies, standards, and reference architecture.
Cost and Benefits: Metrics and measurement requirements.
Building Blocks: Shared services infrastructure requirements and standardized tools.
Projects and Applications: SOA mapping to projects and applications.
Organization and Governance: Governance and compliance structures and policies.

SOA roadmap definition
This phase is where the SOA roadmap is initially defined. A complete gap analysis should be performed for your corporation's SOA goals and appropriate timelines, based on the information gathered in the previous three phases. Near-term events will be more detailed, while later events will be more fluid—so that they may incorporate lessons learned as you move forward.

Business Strategy and Process: Opportunity alignment by business value.
Architecture: Near-, medium-, and long-term reference architecture roadmap.
Cost and Benefits: Roadmap of future metrics, cost structures, and benefits cases.
Building Blocks: Prioritization of shared services strategy and standardized processes.
Projects and Applications: Project and application impact.
Organization and Governance: Proposed governance structures and policies.
Your SOA roadmap should be treated as a "living document" that continually captures experiences and lessons learned. As your roadmap matures, your SOA initiative will reach higher levels of sophistication in a controlled manner (see Figure 2).

What Is an SOA Roadmap and Why Do You Need One?

What Is an SOA Roadmap and Why Do You Need One?

SOA Service-Oriented Architecture is an IT strategy that organizes the discrete functions contained in enterprise applications into interoperable, standards-based services that can be combined and reused quickly to meet business needs. The benefits of SOA will be realized only if the balance between the long-term goals and the shorter-term needs of the business are preserved. This balance can be maintained by instituting a set of organizational, financial, operational, design, and delivery practices from the outset of your SOA initiative. But rather than taking a "big bang" approach, it is important to deploy culture-changing disciplines in an incremental and iterative fashion to allow for an organizational learning curve. In essence, an SOA roadmap provides an iterative and incremental way to capture (and recapture) your organization's unique plan as you progress.

Your SOA roadmap should contain three critical characteristics:

Maturity: Treat your SOA roadmap as a "living document" that continually captures experiences and lessons learned. As your SOA roadmap matures, your SOA initiative reaches higher levels of sophistication in a controlled manner. The creation of an SOA roadmap begins with an assessment of your organization's current capabilities and disciplines applicable to SOA. This process can be initiated by using BEA's Online Self-Assessment Tool.

Scope: A complete SOA roadmap should encompass six domains (see Figure 1). These domains, while distinct, are interrelated and interdependent. Executing on each domain is fundamental to the success of an enterprise-wide SOA initiative. The SOA roadmap should clearly delineate the boundaries of your SOA initiative and establish a transparent and flexible timeline for achieving SOA goals. These goals should be broken down into manageable phases, which can then be realized in an iterative and incremental manner.

Quality: By applying a "Learn & Adapt" process at each milestone, and by being both iterative and incremental, your roadmap will remain relevant throughout the SOA initiative. To ensure your SOA roadmap's quality, communicate and validate it with all stakeholders, soliciting feedback and buy-in from all quarters.

Road to SOA: SAP to address customer pain

Road to SOA Service Oriented Architecture : SAP to address customer pain by Robert Westervelt

SAP is packaging software and consulting services to steer customers on a smoother path to a service oriented architecture (SOA) and ease the learning process of its NetWeaver development and integration platform.

SAP unveiled an Enterprise Services Architecture Adoption Program that will give customers a series of educational workshops and tools to build a roadmap for using NetWeaver to establish a complete service oriented architecture SOA. The program is being offered in conjunction with SAP products that are built on NetWeaver.

The Enterprise Services Architecture (ESA) concept was introduced by SAP in 2003. It was used to showcase NetWeaver and how companies can upgrade their architectures in a step by step process to build an SOA service oriented architecture.

The workshops will take into account specific company architectures and develop a tailored plan to move to an SOA service oriented architecture. A total cost of ownership discovery session is also included.

SAP is in a foot race with its competitors, Oracle Corp. and Microsoft, to develop products that support an SOA, according to analysts. Getting customers familiar with its NetWeaver platform and educated about its ESA strategy has been the theme emanating for several years from SAP's Waldorf Germany headquarters.

With a saturated ERP market, making inroads by developing an open architecture could create new business for SAP, analysts say. As Oracle Corp. combines the software code it acquired from its recent merger with PeopleSoft, developers on what Oracle calls "Project Fusion" must migrate the code to a more open environment, said Paul Hamerman, vice president of enterprise applications at Cambridge, Mass.-based Forrester Research Inc.

"SAP is further along in its SOA build out strategy than Oracle at this point," Hamerman said. "Fusion is based to a large degree on the code that exists in the E-Business Suite, so developing an open environment will not be easy for Oracle."

SAP hopes a better educated customer base will get more customers developing composite applications and SAP's Master Data management technology. Over the next three years, SAP will dramatically accelerate the revamping of its products, said Jim Shepherd, vice president of research at Boston-based AMR Research Inc.

"The vision of breaking the enterprise application suite into a portfolio of configurable process components has been a key part of SAP's strategy for many years," Shepherd said recently in a research brief to AMR clients. "The company believes it is very important to quickly complete the transition to an [SOA] before competitors like Oracle or Microsoft can bring their next-generation products to market."

Composite apps, called xApps by SAP, snap into place on top of the existing applications its customers may have, regardless of platform or vendor. Composite applications pull together relevant data from across a company's applications and should result in streamline business processes, said Ori Inbar, vice president of product marketing, for SAP NetWeaver.

"By now people understand the value of an SOA and know that it's not easy and want guidance on how to do this," Inbar said.

The ESA Adoption Program will be provided initially by SAP Consulting, but SAP plans to eventually allow its partners to conduct the workshops.

"Changing your architecture into a service oriented architecture is not something you do over night. It's a journey," Inbar said.

Source: http://searchsap.techtarget.com

Successfully Planning for SOA - Part 1

Successfully Planning for SOA : Taking a strategic approach to realizing SOA (Part 1) by David Groves

As you continue to develop your IT architecture, it becomes clear that the route to achieving real business benefits requires a fundamental change in the way you think about system design. In this article on services-oriented architecture (SOA), I'll share with you helpful tips, insights, and a domain model to help you plan this change, and ensure the success of your SOA implementation.

SOA: A New Way of Thinking

Albert Einstein once said, "The significant problems we face cannot be solved at the same level of thinking we were at when we created them." In today's enterprise computing, this suggests that the challenges IT faces in delivering successfully to the business cannot be overcome without changing the way we think about IT. For developers and enterprise architects alike, services-oriented architecture SOA provides a structure for that change. The question then becomes: How do we migrate to that new level? How do we prepare for such a fundamental change? How do we do so in the most cost-effective, least organizationally traumatic way possible? The answers begin with proper planning.

SOA services-oriented architecture is not so much a technology as it is a way of thinking. It is bold agenda for infrastructure reformation and represents a culture shift in how we employ technology and work together. Its sudden popularity is less a product of hype than it is recognition of SOA services-oriented architecture as an evolution towards providing closer alignment between our business and our IT systems. Also, that evolution is stunning and far reaching in its implications for the success of our enterprise.

What Is SOA, Really?

Service-oriented architecture is an IT strategy that organizes the discrete functions contained in enterprise applications into interoperable, standards-based services that can be combined and reused quickly to meet business needs.

A service is a module of code, governed by a service level agreement, which can be accessed via a standards-based interface. Each service represents a piece of functionality that maps explicitly to a step in a business process. Services can either be written from scratch or mined by exposing modules of existing system functionality from previously "silo-ed" applications.

Over time, a catalog of services can be built up, allowing business functionality to be fluidly accessed and reused across many different systems. In this way, SOA services-oriented architecture can eliminate duplicate data, rekeying of information, and human error at the tactical level while enabling strategic change - for example, by creating a single view of the customer, and in the process opening up new possibilities for cross-sell, up-sell, and offering services for a more attractive user experience.

New Infrastructure Paradigm

Part of the paradigm shift of SOA is a move from application infrastructure to service infrastructure. Prior to SOA services-oriented architecture, applications were organized into "silos" with point-to-point connections. SOA uses the same back-end application engines and middleware, but leverages a converged Service Infrastructure Layer (Figure 1).

Implementing SOA

As you begin to implement SOA, use the following formula:

• Think Strategically, Execute Tactically: Start by realizing a single-core process with simple, agnostic services that span multiple business units
• Top-down: Identify the services required to support this single-core process
• Bottom up: Identify functions in existing systems that could be exposed as services to support this process
• Infrastructure Services: Identify common supporting functionality requirements
• Expand Slowly: Technically challenging projects may be undertaken concurrently after initial projects have proven successful
• Build an Application Catalog: On a project-by-project basis, harvest and reuse service modules, thereby reducing your cost curve over time
• Focus on Benefits: Phase projects in order of ROI, in stages that include plateaus for consolidation

Using the BEA Domain Model To Plan Effectively

• To be successful, SOA requires IT and the business to work together in new ways. As you plan for services-oriented architecture SOA, you will need to create an effective balance between the technical and nontechnical elements. To this end, BEA has developed a domain model (Figure 2) to help guide you through planning the six key areas that must be given equal consideration to ensure a successful implementation. The first three (Business Strategy and Process, Architecture, and Cost and Benefits) are a good place to begin the planning process.
• Business Strategy and Process: Mapping services-oriented architecture SOA to Your Business

SOA maps IT functions to your business processes, thereby enabling business improvement over time. This mapping process is best expressed as follows:

Analyze: Study processes and identify the supporting functionality required
Develop: Harvest functionality from existing IT assets, develop new functionality, and ensure that all services have clear service-level agreements.
Utilize: Orchestrate services into processes, measure alignment with strategy, and identify opportunities for optimization

Architecture: Defining Long-term Needs
Establish a reference architecture for your IT organization. This is not a current state diagram, but a long-term vision to build against, which should incorporate a two-to-three year architectural vision of where your business is heading. Take the time to define your architecture's guiding principles and policies, but be wary of making those guidelines an end unto themselves. The flexibility and modularity of the services-oriented architecture SOA system should take first priority.

Cost and Benefits: Demonstrating Immediate Business Value
SOA is designed to hit the ground running, and it is important to prioritize the development of services in a cost-benefit order, so that your services-oriented architecture SOA shows ROI from the start. With careful planning, "start-up" costs can largely be absorbed into existing budgets. Over time, the reuse of service modules ensures a lower start-up cost for each new business application. Ensure measurability by setting your baseline at the beginning of your implementation, and avoid the need for backfilling down the road.

Using the SOA Maturity Model
BEA's SOA Maturity Matrix will help you to monitor your services-oriented architecture SOA rollout, thus helping you to monitor your progress against the different phases of development. This matrix is divided into three stages: exploring, expanding, and Exploiting. To assess your architecture's maturity level, you may use BEA's Online Self-Assessment Tool (www.bea.com/soa).

Conclusion
It has been my goal in this article to offer you some pointers for organizing successful services-oriented architecture SOA planning, and my belief is that in taking this approach you can achieve the smoothest SOA rollout possible, and move your organization on to the next level of your development and business agility. For more information on BEA's SOA solutions, please visit www.bea.com.

Source: http://soa.sys-con.com

Successfully Planning For SOA, Building Your SOA Roadmap - Part2

Successfully Planning For service-oriented architecture SOA, Building Your SOA Roadmap (Part 2) by Stephen Bennett

In this second article about service-oriented architecture (SOA), I offer a concrete plan, along with tips and insights, to help you build an effective SOA roadmap, and to help ensure the success of your service-oriented architecture SOA initiative.

Any great journey starts with a goal or destination, and your organization's decision to implement service-oriented architecture SOA is no different. However not unlike the pioneers who set off west in their wagons, you may start with only a vague idea of what awaits you, or how you might get to your destination. To be successful, you must assess your strengths and weaknesses, establish clear direction, choose a route, and then consistently reassess that route as you follow it. You must, to put it simply, create your own unique map for your journey.

What Is an SOA Roadmap and Why Do You Need One?

Service-oriented architecture SOA is an IT strategy that organizes the discrete functions contained in enterprise applications into interoperable, standards-based services that can be combined and reused quickly to meet business needs. The benefits of SOA will only be realized if the balance between long-term goals and the shorter-term needs of the business are preserved. This balance can be maintained by instituting a set of organizational, financial, operational, design, and delivery practices from the outset of your SOA initiative. However it is important that these culture-changing disciplines are deployed in an incremental and iterative fashion, rather then a "big bang" approach, which allows for an organizational learning curve. In essence, an SOA roadmap is an iterative and incremental way to capture (and recapture) your organization's unique plan as you progress.

Your SOA Roadmap should contain three critical characteristics:

Maturity: Treat your service-oriented architecture SOA Roadmap as a "living document" that continually captures experiences and lessons learned. As your SOA roadmap matures, your SOA initiative reaches higher levels of sophistication, in a controlled manner. The creation of an SOA roadmap begins with an assessment of your organization's current capabilities and disciplines that are applicable to service-oriented architecture SOA. This process can be initiated by using BEA's Online Self-Assessment Tool (www.bea.com/framework.jsp?CNT=index.htm&FP=/content/solutions/soa/).

Scope: A complete SOA roadmap should encompass all six domains (see Figure 1). These domains, while distinct, are interrelated and interdependent. Executing on each domain is fundamental to the success of an enterprise-wide SOA initiative. The service-oriented architecture SOA roadmap should clearly delineate the boundaries of your SOA initiative and establish a transparent and flexible timeline for achieving SOA goals. These goals should be broken down into manageable phases, which can then be realized in an iterative and incremental manner.

Quality: By applying a "Learn and Adapt" process at each milestone, and by being both iterative and incremental, your roadmap will remain relevant throughout the service-oriented architecture SOA initiative. To ensure your SOA roadmap's quality, communicate and validate it with all stakeholders, soliciting feedback and buy-in from all quarters.

How to Build an SOA Roadmap

There are four phases to developing your service-oriented architecture SOA roadmap: SOA planning, SOA maturity assessment, SOA future vision, and SOA roadmap definition.

SOA Planning
During this phase, your service-oriented architecture SOA initiative is organized and defined. Stakeholders are brought into the process through communications and briefings, and mutually agreed upon priorities and parameters are set. Because this phase involves employees across your organization, clear and ample communication is critical. During this phase you will:

Define the scope of SOA service-oriented architecture
Establish boundaries and alignments with other IT initiatives
Appropriately showcase the business justification for SOA
Show alignment of existing and future business initiatives

SOA Maturity Assessment

During the service-oriented architecture SOA maturity assessment phase, you will establish a metric for where you are today. Here you will define what services and capabilities you currently have that can serve as a starting point for SOA, as well as identify projects that might serve as foundation projects. Through a series of interviews and questionnaires, your teams should examine the various domains - analyzing, base-lining, and validating the "as-is" current situation for each. Use of BEA's domain model allows you to structure your examination of the following:
Business Strategy and Process: A top-down view of business strategies and processes
Architecture: A review of current architectures, policies, and standards
Cost and Benefits: Overview of existing cost structures and benefits cases
Building Blocks: An analysis of existing services, processes, tools, and technologies
Projects and Applications: Review of existing systems and in-flight and planned projects
Organization and Governance: Analysis of existing governance structures and policies

SOA Future Vision

In this phase, teams use workshops to determine and define the future desired "should-be" state and ensure cross-organizational buy-in:
Business Strategy and Process: Correlation of service-oriented architecture SOA future vision with business strategies and processes
Architecture: Architecture guiding principles, requirements, policies, standards, and reference architecture
Cost and Benefits: Metrics and measurement requirements
Building Blocks: Shared services infrastructure requirements, standardize tools
Projects and Applications: SOA mapping to projects and applications
Organization and Governance: Governance and compliance structures and policies

SOA Roadmap Definition

This phase is where the service-oriented architecture SOA roadmap is initially defined. A complete gap analysis should be performed for your corporation's SOA goals and appropriate timelines, based on the information gathered in the previous three phases. Near-term events will be more detailed, while later events will be more fluid - so that they might incorporate lessons learned as you move forward.
Business Strategy and Process: Opportunity alignment by business value
Architecture: Near-, medium-, and long-term reference architecture roadmap
Cost and Benefits: Roadmap of future metrics, cost structures, and benefits cases
Building Blocks: Prioritization of shared services strategy and standardized processes
Projects and Applications: Project and application impact
Organization and Governance: Proposed governance structures and policies
Your service-oriented architecture SOA roadmap should be treated as a "living document" that continually captures experiences and lessons learned. As your roadmap matures, your SOA initiative will reach higher levels of sophistication in a controlled manner (see Figure 2).

Conclusion
The goal of this article is to provide you with a framework for creating your own SOA roadmap, and an explanation of why that roadmap is so important for your service-oriented architecture SOA initiative. Your roadmap is your guide for what to develop, when to develop, and when to deploy what you've developed, and should be your single most powerful tool for a smooth deployment of service-oriented architecture SOA. For more information on BEA's SOA solutions, please visit www.bea.com/soa.

References
BEA Domain Model Whitepaper (PDF): http://contact2.bea.com/bea/www/soarc/ login.jsp?PGM=1&PC=10SOSO4
Successfully Planning for SOA: http://contact2.bea.com/bea/www/soarc/ login.jsp?PGM=1&PC=10SOSO4

Source: http://webservices.sys-con.com