What's the relationship between SOA,Netweaver and XI

[Former Member]

Hi all,

I'm curious about SOA. and want use this new tech to implement for our SAP Systems and Non-SAP Systems infrastructure. So could someone tell me what the relationship between them. Like if I want to implement SOA, do we have to use Netweaver platform and XI ?

Regards,

Robin Zhao

Edited by: Robin Zhao on May 13, 2008 9:52 AM

[OwenPettiford · Accepted solution]

So let's keep it simple in a different way :-

SOA = A way of architecting software as a set of loosely coupled building blocks. SAP have create "Enterprise" SOA which is the term used by SAP to describe the overall architecture which applies SOA principles to SAP Software.

NetWeaver = This is the brand name used to cover all of SAP's technology components. These include an application server that supports both ABAP (SAP Language) and Java (WebAS), portal (EP), business intelligence (BI), master data management (MDM), Service Repository (ESR/UDDI), ESB/Integration Broker (PI/XI) and development tooling (Composition Environment (CE) / Mobile) - these can all be used in an Enterprise SOA flavour or as "traditional" architecture components.

XI(PI) = Now called Process Integration (PI), in a technical component that can be used as a traditional Integration Broker (A2A and B2B interfaces), an ESB and.or a UDDI (called ESR by SAP).

You don't need to used NetWeaver to do SOA, but if you don't use it in an SAP centric environment you will have to maintain all your SOA metadata (data types/service definitions) yourself, if you use NetWeaver you get 90% of this content delivered.

[Former Member · Accepted solution]

Thanks Owen for your detailed explanation. As you said, the Netweaver support ABAP (SAP Language) and Java (WebAS), so does the Netweaver also support Microsoft .Net platform and what's newest version of Netweaver platform?

Thanks & Regards,

Robin

[sbhutani1 · Accepted solution]

Hi Robin,

SAP Netweaver platform is built upon two engines i.e. JAVA Engine and ABAP Engine. You can only integrate .NET applications with SAP using ESOA platform but you can't develop .NET applications inside SAP because till now there is no support for .NET IDE inside SAP.

SAP and Microsoft is working towards creating a solution for the same.

Also please refer the below link for more details on SAP Netweaver. You will find lots of useful information regarding .NET and Netweaver here.

http://www.thespot4sap.com/articles/SAP_Netweaver_Introduction.asp

Regards

Sumit Bhutani

[Former Member · Accepted solution]

Hi Robin,

Netweaver platform consists of ABAP and Java. Most of the product works either with only ABAP , only Java(eg EP) or both ABAP and Java( eg. PI).

.Net support/connectivity can be achieved using DCOM and SOA/Web Services. But base of Netweaver doesn't include it.

The latest version of Netweaver is 7.0(2004s) and the version which is in ramp up or released for evaluation purpose is 7.1.

Till date only one product from netweaver 7.1 suite i.e. CE 7.1 along with ESR are available to customers, rest all are in ramp up( like PI 7.1, Mi 7.1)

ESR and UDDI are different . ESR is the metadata for service definitions and UDDI is the registry for developed services.

Hope this helps.

Regards,.

Piyush

[OwenPettiford · Accepted solution]

I believe the other posts to your question answer most of your questions. I would add.

SAP have just delivered the Enterprise Services (ES) Explorer for .NET, this is a plug in to Microsoft Visual Studio which allows you to browse the (E)SR (Enterprise Services Registry - the UDDI bit of the ESR). If you sign up for the hosted ES Worklplace you can use this to start writing .NET apps that cal SAP. If you want to do this then we will be doing a series of blogs about it soon.

Also Duet is a co-developed product from SAP and Microsoft that provides pre-built integration to Office Apps. See Duet.com

[sbhutani1]

Hi Robin,

In a very simple sentence, Netweaver is a platrorm, SOA is a stretegy and XI is the methodology to implement SOA stretegies on Netweaver Platform....hope this is enough for relationship between these entities.

Regards

Sumit Bhutani

[OwenPettiford]

XI is a product not a Methodology

[MendelKoerts]

Robin,

Important basic thing to understand is that SOA is just a design concept, that comprises various design principles. In order to develop an IT environment based on these SOA design principles, specific IT components are required. These can now be found in the NetWeaver stack, like in PI7.1.

Mendel

[former_member472138]

Hi

pls see the below link

https://www.sdn.sap.com/irj/sdn/advancedsearch?query=toolstoimplementSOAprojects&cat=sdn_all

The goal of a service-oriented business architecture (SOA) is the loose coupling of business services. In order to enable such a service-oriented business architecture users require a SOA runtime platform. As of today, enterprise users face a number of challenges in operating these SOA runtime platforms, e.g.

SOA Platforms consist of a set of internal technical services (e.g. registry, messaging, and security). Today, those technical services are strongly coupled within most of these platforms. A loose coupling of those services would allow a best of breed approach and would give the user the option to leverage existing software assets

The interoperability between different SOA runtime platforms is often limited to the basic technical services (e.g. messaging). High level interoperability (e.g. business process orchestration) across SOA domains operated on different platforms is often not possible.

The enablement of embedded systems collaborating in a SOA runtime environment.

The SOA platforms available today fall short to these expectations and limit the value of SOA on the user side. This project intends to address these three challenges:

Lack of common interfaces between the technical components of a SOA runtime platform

Lack of interoperability between SOA environments

Lack of SOA runtime deployment on embedded systems, e.g., on medical devices in the healthcare industry

Lack of common interfaces: The different SOA runtime platforms consist of very similar technical components (e.g. service registry, messaging). The lack of common APIs between these technical components means that these components cannot be exchanged. This project intends to develop a common framework/API which treats these components as exchangeable plug-ins.

Lack of interoperability: Although there are ongoing standardization efforts, the interoperability of heterogeneous SOA environments is very limited today. As an example, a BPEL code can usually not be executed across different SOA environments. Rather than introducing yet another new SOA platform, the SOA Runtime Framework introduces a new abstraction layer and allows developers to create adapters to existing SOA platforms.

Lack of SOA deployment on embedded systems: The vast majority of the currently existing SOA environments is exclusively targeted at enterprise environments and demands a considerable amount of memory and processing resources. The SOA Runtime Framework takes a different approach in that all components could potentially be replaced by alternatives with a smaller footprint which renders it equally well suited for both enterprise environments and resource-restricted embedded and mobile devices

Business and IT value chains today have started to merge together in the industry. We now speak of enterprise architecture and Service-Oriented Architecture (SOA) that are independent from IT implementation. With this change, we also need to adapt the way we structure businesses and IT landscape, define and develop architectures like SOA, and run enterprise-focused client engagements.

For all these reasons, governance plays a more important role in today's IT than it ever has before. In this article, I share IBM IT Management Consulting (ITMC) team's best practice governance approach, which we developed and implemented in several client engagements. Starting from proven IT governance structures and practices, I enhanced our governance model to meet SOA requirements.

Motivation and objections

Because of the challenges and issues of the industry, the role of IT in the modern organization has changed radically. Today, IT must react very quickly and flexibly to enable business almost in real time. IT has to design and manage part of a highly integrated and complex enterprise architecture, with increasingly blurred boundaries between business and IT components. This article proposes key governance functions that will help you achieve these goals and implement successful SOA engagements.

Governance provides an overarching structure in order to support the customers' business objectives on strategic, functional, and operational levels. It defines the rules, processes, metrics, and organizational constructs needed for effective planning, decision making, steering, and control of the SOA engagement to achieve customers' business needs and challenging targets. Finally the governance model defines:

What to do.

How to do it.

Who should do it.

How it should be measured.

The model also defines the rules, processes, metrics, and organizational constructs needed for effective planning, decision making, steering, and control of the SOA engagement to meet the customer's business needs and challenging targets.

Based on our experience, we believe that an accepted and formalized governance model is key for successfully achieving business objectives. Therefore, we propose to establish governance functions in SOA engagements. The governance model should also address the fundamental requirement of incremental adaptation, with a focus on using the lessons learned in each step to define and execute the next step. The creation of a governance body for the adaptation and implementation of SOA is a core requirement of the governance model. To achieve fast and high acceptance, we advocate using the client's existing organization and working together to adapt it to the SOA engagement.

The governance model: The right shape for SOA engagements

There are different definitions of IT governance. The one from the IT Governance Institute (see Resources for a link) gives a good overview of IT governance in general:

IT governance is the responsibility of the board of directors and executive management. It is an integral part of enterprise governance and consists of the leadership and organizational structures and processes to ensure that the organization's IT sustains and extends its strategies and objectives.

The purpose of IT governance is to direct IT endeavors to ensure that IT's performance meets the business objectives so that:

IT's alignment with the enterprise results in the promised benefits being realized.

IT enables the enterprise so that opportunities are exploited and benefits are maximized.

IT resources are used responsibly.

IT-related risks are managed appropriately.

Our governance model illustrated in Figure 1 is a combination of organizational structure, joint processes, and relationships based on the strategic direction and accepted ground rules called governance principles. This approach was developed from our experience in large and complex engagements, where we realized that these elements are fundamental for any kind of a project.

Core governance elements

Strategic direction and guiding principles

The definition of a client's strategic direction is the key to success for developing an appropriate SOA and sustaining focus on business needs. A common understanding of the business strategy and objectives is fundamental for both business units and IT.

Governance principles and guidelines are the fundamental basis for any decision. They will shape the solution area and define the way that collaboration takes place. Therefore, they should be well understood and agreed to by executive management. One main guideline is the governance approach. You can diffentiate between two main approaches:

Central governance: Best for the enterprise. The governance council has representation from each service domain (more on this later) and from subject matter experts who can speak to the people who implement key technological components of the solution. The central governance council reviews any additions or deletions to the list of services, along with changes to existing services, before authorizing the implementation of such changes.

Distributed governance: Best for distributed teams. Each business unit has control over how it provides the services within its own organization. This requires a functional service domain approach. A central committee can provide guidelines and standards to different teams.

Each principle should be defined with a rationale that explains that principle's purpose and implications. Guiding principles define the ground rules for development, maintenance, and usage of the SOA. Specific principles -- for architecture design or service definition, say -- are derived from these guiding principles, focusing on specific themes. These principles are the characteristics that provide the intrinsic behavior for the style of design and should cover the following aspects of the project:

Guiding principles:

Reuse, granularity, modularity, composability, and componentization

Compliance to standards (both common and industry-specific)

Services identification and categorization, provisioning and delivery, and monitoring and tracking

Specific architectural principles:

Encapsulation

Separation of business logic from the underlying technology

Single implementation and enterprise-view of components

Leveraging existing assets wherever an opportunity exists

Life cycle management

Efficient use of system resources

Service maturity and performance

By understanding the principles of the SOA style of architecture and design, along with the benefits of those principles to the business and IT communities, you can determine the applicability of SOA when designing a solution. These principles drive certain characteristics that are essential to the design of a service. You can trace back each of the characteristics to one or more SOA principles that provide integrity to the principles and the characteristics.

Governance processes

Governance processes are those processes needed for strategic IT planning and steering, such as:

Strategy development

IT planning

Portfolio management

Sourcing

Innovation management

Architecture management.

Within SOA engagements, you should establish the Architecture Management Process (AMP) at the very beginning of the engagement. The primary objective of the AMP is to ensure the consistent and efficient development and vitality of the defined SOA.

Based on our experience at many engagements, we developed a standard AMP that you can use and adopt within client engagements quickly and easily. The process consists of four subprocesses, illustrated in Figure 2, that are well-defined and available as an asset using IBM LOVEM notation. (LOVEM stands for line of visibility engineering methodology; see Resources for more information).

. Architecture management process

Let's look at some of the elements of the picture in more detail:

Architecture review and approval process:

Defines a structured approach to review and approves changes to the existing SOA; makes decisions in accordance with the SOA roadmap.

Formal design and service evaluation reviews are key control points.

Architecture exceptions and escalation process:

Provides means to appeal architectural decisions.

Allows exceptions to the SOA architecture to meet unique business needs.

Architecture maintenance process:

Ensures that the SOA is maintained and that changes are communicated to stakeholders as new services are incorporated into the architecture.

Variances to the architecture are documented and communicated.

Architecture communication process:

Ensures that the SOA is available to everyone who needs access.

Promotes the understanding of the importance of the SOA.

Organizational structure

To provide architectural governance, some structures have to be established within an organization, defining all required roles and responsibilities as well as appropriate decision-making structures. Experiences in the field have shown that it is very useful to establish an architecture office, especially in large and complex engagements. The architecture office is responsible for keeping the SOA aligned with the business requirements on strategic, tactical, and operational levels. It includes an architecture design authority, who is the owner of the architecture management process. Furthermore, roles and responsibilities are defined on each level.

From our work on client sites, we recognized two effective ways to establish and run such an architecture office:

If the client organization already has an institution with more or less the same functions as an architecture office, then you should interlink with this existing structure. You need to ensure that all functions and responsibilities are on board for making architectural decisions. For the SOA engagement, the board members should be involved with SOA decisions and need to be kept informed on progress.

If there is no governance council at the client's site, we recommend that you establish an architecture office within the context of the SOA engagement and have it make decisions about key project deliverables. Staff the architecture office temporarily with client and project personnel who are involved in the SOA engagement. Members should be decision makers, and should include the CIO as a sponsor. At the end of the engagement, the architecture office can be integrated into the client organization.

Figure 3 represents the architecture office and the roles and responsibilities it fills on each level. On the strategic level there is the architecture board, which is the decision board responsible for submitting standards and principles and prioritizing services aligned with the business and IT strategy. On the tactical level, the architecture group operates as an architecture design authority responsible for defining the architecture management process, along with decision criteria for changing, removing, or adding services and managing domains. On the operational level, the project team develops and implements the services.

Each team needs a role description defining its tasks and responsibilities and the mode of operation.

SOA governance introduces the notion of domain ownership, where domains are managed sets of reusable services sharing some common business cohesiveness. In many cases these are subsets of business services, such as customer information, case information, merchant dispute statistics, and the like, as well as dispute references like merchant risk rating, product analysis, and planning services. Each domain is responsible for maintaining its own business objects and for publishing interfaces to its services to other domains. The domain offers retrieval and maintenance services for the business object, encapsulating business logic, location, and the format associated with its objects and services. When the people in charge of one product or product area want a service from a domain, they makes a request and the two groups determine the relationship, creating a service-level agreement. These relationships and agreements also exist between domains.

With the concept of domain ownership, there are some more new roles and responsibilities that should be provided for the development life cycle in a SOA engagement, as outlined in Table 1 below.

Table 1. Roles and responsibilities in SOA engagement

Role Description

Domain owner Manages the direction of the domain, which comprises a collection of one or more services, as well as the business relationships to help process owners in various business units understand the business perspective. Works with the data and process owners, using business analysts from the lines of business to clarify business goals and requirements. Tracks usage of services for ROI calculations.

Domain service-oriented business analyst Develops use cases that focus on service functionality with no presumption of a user interface. Ensures that well-abstracted and normalized business services are identified and specified. Must adhere to a service definition and development life cycle that is both rigorous and nimble.

Line of business representative Identifies and analyzes business services for the domains.

Domain developer and maintainer Builds and maintains services consistent with the service-oriented development life cycle. Builds and implements a service that is consistent with development rules (for example, service design considerations or Web services implementation guidelines), the SOA, and the reference architecture.

Service tester Certifies that the service conforms to the litmus test agreed to for a service so that the appropriate business value is obtained. Builds test cases for the functional interface and its implementation independence.

The people working within a given service domain are responsible for developing the business and technical integrations to produce business services that are shared across the lines of business to benefit members and regions. This introduces a change in the organizational structure (roles and responsibilities) for application development, as they shift from developing functionality within an application to developing functionality within a service domain.

Launching the governance model

The process you can use to develop a governance model is based on a three-phase approach. This approach was developed based on time-constrained client engagements. The key to success is the establishment of the governance functions from day one of the engagement.

Step 1: Operationalize

Set the core governance functions in place and support the client's business operation.

Learn by doing; deliver quick wins.

Use well-experienced practitioners to act at the top management level.

Step 2: Professionalize

Build up the necessary structures, processes, methods, and tools.

Adapt experiences from Step 1.

Use experienced architects and method practitioners.

Step 3: Stabilize

Teach and train the client personnel to run the operation.

Change from operation mode to coaching mode.

Use consultants and specialists with coaching expertise

Regards