GRC
HR
SCM
CRM
BI


Article

 

3 Ways to Approach SOA

by Scott Campbell

August 11, 2009

How you implement SOA depends on your company’s IT infrastructure, but the possible approaches fall into three categories: all SAP (enterprise SOA), vendor-neutral, and a hybrid approach based on SAP. Build a roadmap for your SOA implementation by weighing the pros and cons of each approach.
 

Every organization’s approach to implementing service-oriented architecture (SOA) is as unique as its IT landscape, organizational structure, and level of business alignment. For example, organizations with more heterogeneous IT landscapes, a highly decentralized approach to architectural decisions, and divided portfolios of business priorities will find their implementation path very different from that of an organization that has fewer business units, prioritizes initiatives across them, and consolidates its IT infrastructure around platforms and applications such as SAP NetWeaver and mySAP Business Suite. SOA can provide significant benefits to both types of organizations; however, the paths to success will be quite different.

Organizations typically follow one of three approaches when deciding whether to adopt SOA:

1] SAP’s enterprise SOA: These organizations have made the decision to standardize on SAP’s methodology, tools, and infrastructure for SOA, and consolidation plans to eliminate non-SAP applications and redundant technology infrastructure that can now be supported with the SAP NetWeaver platform are in place. Third-party solutions may be acquired from vendors that are actively participating in the SAP ecosystem and have worked with SAP to deliver certified solutions that complement the SAP NetWeaver platform.

2] Vendor-neutral SOA approach: Organizations taking this approach have built an SOA infrastructure that supports multiple vendor platforms. They tend to have heterogeneous environments and many legacy applications vital to the SOA solution. They also tend to be strong at managing custom application and integration efforts and supporting high-availability infrastructures. Enterprise SOA adoption efforts are limited to using the SOA-based interfaces provided by SAP.

3] Hybrid approach: Organizations that adopt the hybrid approach tend to have large SAP footprints that they have complemented with another vendor’s platform, such as IBM WebSphe re, BEA WebLogic, or Microsoft .NET. They tend to have two development camps with clear lines between what is done within SAP versus within another platform.

Where Your Choices Take You

Let’s look at the following three areas and see how your organization’s choices regarding SOA can influence your roadmap.

1] Services: The value you get from your SOA efforts will be severely limited if you can’t properly manage a coherent set of services that are reused across various projects within the company. In fact, many SOA programs have stalled or failed altogether when they moved beyond an easily managed number of services because the company did not adopt a governance strategy. What characteristics make a service valuable?

  • Locatable: Potential users need to know that the service is available.

  • Reachable: It needs to be programmatically accessible, so it uses the correct protocols, offers suitable test and development capabilities for evaluation, provides the appropriate proxies, and so forth.

  • Well-documented: A user can figure out what the service does by reading the documentation.

  • Usable: The service is open and defined widely enough to apply to a variety of circumstances.

  • Policy-based: It must support the company policies that its users need to follow.

  • Adaptable: It can be augmented and customized without much difficulty.

  • Managed: Users can trust that the service will work when they need it.

  • Encouraged: Users have an incentive to use a service to perform a certain action.

Another challenge occurs in organizations with multiple packaged non-SAP applications in addition to those from SAP. Since most vendors are working to service-enable their business solutions, you must integrate multiple service libraries from different vendors. Of course, the level of granularity, required metadata, and semantics vary among libraries, leaving it to the organization to resolve the differences (see “Considerations for Managing Your Services Meta-Model,” below).

 

Considerations for Managing Your Services Meta-Model
Enterprise SOA-Centric Approach Vendor-Neutral SOA-Centric Approach Hybrid Approach
Use SAP NetWeaver as a platform to create services from existing assets and evolve from SAP NetWeaver Exchange Infrastructure (SAP NetWeaver XI) integration directory to the Enterprise Services Repository (ESR).
Extend from SAP’s base of published enterprise services.

Participate in the SAP ecosystem efforts as reviewer or proposer of new services.

Acquire services from third parties working closely with the SAP ecosystem.
Consider a third-party repository in the short run.
Select a primary repository.
Develop a governance process for your preferred service model.
Expose third-party applications like SAP’s according to your internal model and in your preferred repository.

 

Develop strategies for working with multiple repositories.
Rationalize the enterprise SOA services inventory with other existing assets into a hybrid repository.
Determine criteria for which platform to use to create and control which services.
Acquire services from third parties that work closely with the SAP ecosystem when appropriate.

2] Client implementations: SAP NetWeaver offers a number of tools and technologies for creating user interfaces (UIs) or applications that consume enterprise SOA services. Here is a brief list:

  • SAP NetWeaver Portal for role-based user-productivity interfaces

  • Web Dynpro for model-driven UIs, which can be deployed in a variety of formats

  • SAP NetWeaver Visual Composer for business and systems analysts to quickly assemble applications

  • SAP Composite Application Framework (SAP CAF) for building rich composite applications (xApps) that can include guided procedure functionality

  • Process integration and application server capabilities, which can consume services in multi-step application-to-application (A2A) and business-to-business (B2B) scenarios

Since SAP NetWeaver is an enterprise SOA platform, this list barely scratches the surface of what you can do with the tools to create service-oriented clients. Other SOA platforms such as Microsoft .NET and IBM WebSphere, and a number of “best-of-breed” composite application development and business-process management (BPM) tools can also work with SAP services.

Your approach to enterprise SOA versus vendor-neutral SOA adoption will largely determine which client development technologies you focus on (see “Considerations for Creating SOA-Based Applications,” below, summarizing the decisions you need to make regarding training people, building methodologies, and implementing infrastructure to create SOA-based client applications).

Considerations for Creating SOA-Based Applications
Enterprise SOA-Centric Approach Vendor-Neutral SOA-Centric Approach Hybrid Approach
Use SAP NetWeaver to build and deploy service-based applications.
Leverage SAP’s xApps and third-party-certified packaged composites as they are released.

Make interim decisions on the importance of BPM tools.

Where appropriate, select best-of-breed SOA-based composition and BPM tools.
Enable developers to create clients that call SAP services on their platform of choice (e.g., Microsoft Visual Studio).
Joint training and support for multiple platforms.
SAP-centric development focuses on SAP NetWeaver.
Non-SAP-centric development has a defined toolset of choice.

3] SOA runtime infrastructure: Of all the areas where SOA and enterprise SOA adoption balancing take place, the area of infrastructure selection is probably the most difficult. Standards are changing quickly in this area. More important, vendor capabilities vary widely, as do the overall architectural models.

The reason for this variation is that the market so far is immature for a robust SOA infrastructure. Web service standards are still limited so the majority of enterprise-class support for non-functional requirements is non-standard. Thus, vendor design and runtime infrastructures are dependent upon each other. For example, using SAP NetWeaver for client implementations requires that you use SAP’s infrastructure platform in production. The same is true with most of the leading application-vendor development platforms, as well as best-of-breed products.

Below are some of the capabilities needed in an SOA runtime infrastructure:

  • Messaging and service intermediation, including an enterprise services bus (ESB), to ensure loose coupling

  • Runtime registry, repository, and policy management to manage service elements as assets, automate certain governance tasks, and promote reuse

  • Legacy enablement to leverage your existing, non-service-enabled functionality

  • Service-network monitoring to support service-level agreements (SLAs) and manage the infrastructure

  • Functional load and integration testing to perform quality assurance (QA) on service-oriented solutions

  • Orchestration engine to reliably execute and monitor complex, process-based interactions

  • xApp lifecycle management engine to manage the integrity of business solutions, which span multiple underlying services and application components

  • XML transformation and acceleration to handle semantic integration and improve performance

Debates in this area can be interesting. For example, there is great debate around whether an ESB is any product that implements a specific set of service-intermediation functionality, or whether the product also has to adhere to strict implementation principles. For instance, does an ESB need to be loosely coupled with messaging infrastructures, and must it be able to be deployed in a distributed fashion near service endpoints?

The SAP NetWeaver intermediary is currently SAP NetWeaver XI, which is designed much like an enterprise application integration (EAI) broker. In some organizations that architecture conflicts with their SOA reference-architecture plans, and they augment their environment with a best-of-breed SOA infrastructure. The problem is that some of these choices are expensive to implement and carry a high switching cost. This expense has kept some organizations from moving beyond the “grass roots” level of SOA adoption (see “Considerations for SOA Runtime Infrastructure Decisions," below).

Considerations for SOA Runtime Infrastructure Decisions
Enterprise SOA-Centric Approach Vendor-Neutral SOA-Centric Approach Hybrid Approach
Use SAP NetWeaver as a service
infrastructure within or between
SAP deployments.
Use SAP’s ESR as it is released for SAP-based enterprise services and xApps.

Augment with third-party “best-of-breed” products in the short run with plans to retire them when an SAP or ecosystem partner product becomes available.

Use a lightweight service infrastructure for communication between platforms/ESBs.
Implement enterprise-wide strategy to effectively handle multiple service repositories at runtime (SAP and non-SAP).
Design and implement an enterprise-wide service infrastructure strategy optimized to your business.
Develop specific case-by-case scenarios in your reference architecture.
Augment SAP NetWeaver with infrastructure from other client implementation tools you have selected.

Becoming a Service-Oriented Enterprise

The business-driven architecture model is a conceptual framework for aligning business and IT. When business strategy drives processes, the ideal service model for the organization can be determined by identifying the functionality needed to support those critical processes (see “The Business-Driven Architecture,” below). The service model itself should be implemented on a standards-based technology platform, which supports composition and enables consolidation, as opposed to the proprietary solutions that come with many of today’s BPM-oriented software suites.

The business-driven architecture shows the alignment between what typically have been disparate activities and models. The value of bringing these together is more efficient IT from a cost standpoint, as well as more effective IT by aligning with company strategy and processes. The other benefit is the clear alignment of the processes themselves with strategy.

To become a service-oriented enterprise, you need to consider three strategic areas: service-oriented strategy, service-oriented architecture, and service-oriented methodology; and three implementation areas: service-oriented integration, service-oriented enablement, and service-oriented construction.

Of course, there is no one path to service orientation, and companies don’t need to go through all six concerns to fully realize SOA. However, a clear understanding of these areas, and effective planning to address them (today or in the future), is critical to achieving long-term success.

Service-Oriented Strategy

Done properly, SOA is a strategic shift in how business and IT collaborate to leverage technology for competitive advantage. Service-oriented strategy is designed to leverage classic business-strategy techniques and map IT goals, objectives, and tactics. These steps can help move your organization’s service-oriented strategy forward:

Form an expert team: SOA adoption is ideally a cross-functional task, with representation from central and distributed IT, from business as well as technical people. Make sure that your core SOA team is well represented by architects, developers, business users, IT operations, and even key partners.

Develop an SOA strategy and vision for your company: The primary role of the expert team should be to develop an SOA vision, strategy, and roadmap, and then to seek executive sponsorship and leadership. The vision should have clear goals, objectives, and measurements, along with a baseline assessment. The best sources of value are consolidation for cost-reduction and the solution of high-ROI business-process issues using SOA techniques.

Identify pilots to test your strategy: Your strategic-planning exercise should identify some important, but not mission-critical, candidates for an SOA pilot.

Allocate budget for evangelism and education: While your expert team will soon become SOA veterans, it is important that key people throughout the organization understand SOA and be brought into what you are doing early in the process. Spend time and money sharing the SOA vision and sponsoring key leaders throughout the organization through basic SOA training.

Service-Oriented Architecture

SOA is a new architectural approach, and therefore developing and implementing the proper architecture is critical for success. To achieve that, you should:

Develop your SOA reference architecture: No single architectural approach is right for all companies. It is critical that you develop an architectural profile that fits your company’s unique environment and requirements. At the core of any SOA should be an infrastructure that decouples common concerns and delivers them through the network (see “Enterprise Services Network/Fabric/Bus,” below).

These roles show some of the many types of services that should exist within the infrastructure to support effective use of SOA. Traditionally, each of these areas was left in the hands of individual solution-development teams, but now they can be decoupled from solutions and shared as common capabilities within an SOA network.

Address governance concerns: Without the proper planning and governance structure, your SOA initiative won’t scale beyond a few applications and will introduce the same technical and organizational challenges your current systems have, but probably on a much larger scale. Fundamentally, you cannot turn services into reusable assets if your developers don’t know how to find them or access them at runtime. Before you go too far down the path of creating and deploying new service-based applications, it is important to enforce your SOA and encourage use through a proper governance structure.

Ensure alignment from vendors and partners: Although it should be your organization’s SOA, not your vendor’s, it is still critical to ensure that your choice of tooling, standards, and implementation patterns are in sync with your vendors’ visions and roadmaps. SOA is a great opportunity to leverage your existing investments in vendors and systems.

Model planned changes in your reference architecture: This is especially important in terms of enterprise SOA adoption.You may choose to implement near-term SOA infrastructure components or tools in some area that will be retired as SAP NetWeaver implements more of the enterprise SOA strategy. Knowing how your reference architecture will change over time and having a plan for consolidation is vital.

Service-Oriented Methodology

The method for developing services and service-based applications is likely different from today’s model of application development. Modern methodologies must extend beyond the technical nuts and bolts to provide the fabric that weaves business strategy, processes, and technology together.

Update your development methodology: The goal of your new methodology should be to create repeatable processes that inherently move your SOA projects from an art to a science, lower the risks, and increase the rate of success.

Put up a services portal: You don’t need a fully deployed registry or 100 Web services to put up a basic developers’ portal. Make it easy for your developers to find valuable internal services, encourage best practices and information-sharing, and build a sense of community.

Break down cultural barriers: SOA changes organizational norms and boundaries, and forces new people to work together — architects and developers, managers from competing business units, and so on. Sponsor a brown-bag lunch, or even better an SOA “mixer,” to encourage SOA participants to break down these barriers.

Service-Oriented Integration, Enablement, and Construction

Integration, enablement, and construction are the three SOA implementation concerns. Integration transforms messaging middleware into a more ubiquitous, standards-based model; enablement unlocks existing assets as services; and construction lets you build well-designed services and service-based applications.

Market your early project wins: You probably have already built one or two Web services-based projects with a partner or for simple internal use. Polish those applications and use them to demonstrate that you are already moving down the SOA path.

Adopt SOA pragmatically: While designing the right architecture is important, create some simple Web services to be shared globally — common utilities used in many applications such as customer account look-ups. These drive immediate value as opposed to ongoing architecture work that never seems to go live.

Start Small

SOA has emerged as the industry architectural model most likely to solve the issues of adding business-process agility and lowering total cost of ownership (TCO) in IT landscapes. Because of unprecedented levels of vendor support and cooperation, it’s only a matter of time before service-oriented computing becomes a mature part of many IT environments.

SAP’s commitment to enterprise SOA is broad and visionary, and the company’s roadmap will address a number of key questions surrounding how enterprise applications change in an SOA world. Even though some aspects of the enterprise SOA roadmap are not yet available, there are plenty of ways to get started on adoption today because many advantages of service-oriented computing can be realized at a local level on a project-by-project basis. Just keep in mind that ultimately the value proposition for enterprise SOA requires higher organizational or enterprise-level cooperation to deliver the greatest benefits. The good news is, starting small is actually the safer approach and has more impact.

Whether you are taking a vendor-neutral approach to SOA adoption and limiting the use of SAP development and infrastructure technologies or are seeking an SAP enterprise SOA model, there are plenty of options for you to get started with SOA. With careful planning whatever approach you take can be future-proofed to maximize any future SAP enterprise SOA solutions that you might adopt.

SOA Adoption in the Trenches

A quick snapshot of three Global 1000 companies’ SOA adoption process demonstrates that successful adopters take similar paths:

  • An electronics manufacturer has 180 services in production, several based on SAP. Company is using third-party registry and ESB products, and is taking a hybrid approach with its reference architecture to include SAP and a second strategic application platform.

  • A consumer-products company has 28 services in production shared by multiple business units. Using a third-party intermediary, it is timing its SOA adoption in conjunction with a future mySAP ERP upgrade.

  • A pharmaceuticals conglomerate has 112 services in production, across multiple business units. It adopted a pure SOA strategy, building a service model on top of SAP for its own internal enterprise service definitions. Company will use service-oriented integration with SAP, and rely primarily on its internally developed Web Services Description Languages (WSDLs).

Each company embarked on strategic SOA initiatives based on three main principles:

1] Plan strategically, adopt pragmatically: Each took an architecture-first approach toward planning its SOA — separating the architecture into logical layers and ensuring that the architecture was loosely coupled and truly platform-independent. Each also created some simple services early on to demonstrate success in infrastructure and reuse.

2] Commit to SAP: Each company used SAP NetWeaver Application Server (SAP NetWeaver AS) and SAP NetWeaver Portal where appropriate, and planned its long-term reference architecture to align with SAP’s enterprise SOA.

3] Balance SAP commitment with third-party technology investments: Each company has invested in technology that augments SAP’s enterprise SOA roadmap, and filled in some of the short-term gaps within the reference architecture. This included “best of breed” service infrastructure intermediaries, custom xApp development tools, service registries, and hardware-based application-integration appliances.

Scott Campbell, co-author of Mastering Enterprise SOA with SAP NetWeaver and mySAP ERP, joined MomentumSI in June of 1998. He leads MomentumSI’s SAP NetWeaver integration practice, which helps organizations plan for SAP’s enterprise SOA roadmap, leverage SAP NetWeaver tools to build process-driven xApps, and mentors developers in working in a Web services and SOA-based environment.

An email has been sent to:






More from SAPinsider



COMMENTS

Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!


SAPinsider
FAQ