Section 3.18. How will modeling translate between enterprises with different architectures? Will a standards body evolve to resolve potential conflicts?

3.18. How will modeling translate between enterprises with different architectures? Will a standards body evolve to resolve potential conflicts?

It's no secret that ESA is SAP's strategy foundation for the future of enterprise softwarea market in which SAP's customers expect the company to provide the lingua franca. But it's also true that no one else has come forward with a language or a set of de facto standards for translating a vanilla SOAa creation of IT, and only ITinto a tool that business users understand.

Erecting an SOA that's technically capable of integrating every one of your systems without involving your managers or your partners is like calling one of your suppliers in China from your cell phone without knowing how to speak Chinese. Cellular networks, undersea cables, and the protocols for transmitting your voice halfway around the world are minor miracles, but what good do they do you if you can't understand the voice on the other end?

SAP developed enterprise services to be the lingua franca spoken by any enterprise that has adopted an SOA. While SAP is leading the charge by virtue of its expertise in this arena, its goal isn't to jealously protect ESA as a proprietary set of standards, but rather to open the definition of services and the platformthe evolution of this languageto the broader community of developers and Independent Software Vendors (ISVs). We explore these issues in detail in Chapter 20.

This is a new position for SAP. Historically, the company has used its industrial-strength applications and market leadership to define from the top down the roles and opportunities available for its partners. However, that was before flexibility, integration, and reuse took center stage. To date, SAP has spoken to more than 1,000 ISVs about inclusion in the ongoing conversation about ESA, and it has struck partnerships with industry leaders such as Intel, Cisco, EMC, and Adobe for hardware and software support of the architecture. SAP has formalized these relationships in what it dubbed the "Enterprise Services Community" (ES-Community), essentially a steering committee for the future development of ESA. SAP, its partners, and their mutual customers (that would be you) will form the three legs of the stool supporting the ESA ecosystem.

Similar in form to the Eclipse Foundation that formed around IBM's Eclipse platform, the ES-Community is envisioned as a standards organization designed to guarantee interoperability, protect participants' intellectual property, and address issues, such as security, which are relevant to every ESA adopter. Over time, SAP hopes the ES-Community's common inventory and repository of services will become the reference guide and marketplace for every available enterprise service. For a more detailed discussion of this issue, turn to Chapter 6.

With that said, SAP isn't the only one pushing for enterprise services adoption, and in the end, its flagship services may not be the ones most relevant to your industry, or even to your own ecosystem of partnerships. Dominant process innovators such as Dell and (especially) Wal-Martwhich unilaterally dictates the terms of electronic data interchange (EDI) with its suppliers and which brooks no dissentare setting both the pace and the adoption path for their partners. We cannot emphasize this enough: ESA is about business logic as much as it is about the underlying process logic. It is quite possiblewe would hazard to say quite likelythat standards, such as they are, will be driven by the users themselves.

If you aren't already dictating those standards to your partners, chances are they will soon be dictating them to you.