Section 1.8. What is the promise of ESA?

1.8. What is the promise of ESA?

Looking back to the answer we provided to the question "What is ESA?" reveals that the answer so far has primarily explained the ESA technology architecture. The next question in this chapter refers to ESA at the application level, and the following chapter is devoted to exploring all of the questions related to understanding the business value of ESA.

The technology architecture came first because that is how most enterprise architects start their understanding of a new trend or idea. First they understand the mechanisms, then they understand what they can do with those mechanisms, and then they determine whether the trend has any relevance to their company's IT situation.

Based on all of the mechanics of ESA that we have explained thus far, we can summarize the likely benefits of systems created using ESA:

• Greater flexibility

• Expanded reuse of existing functionality

• Improved communication between IT and business

• Faster time to market through improved developer productivity based on model-driven development, removing IT bottlenecks

• Easier adaptation through modeling and role-based tools

• Clearly defined roles from the business analysts to the developers

• Better encapsulation to allow heterogeneity or outsourcing

• Lower TCO

• A foundation for an ecosystem

• A foundation for harvesting value from standards

For many SOA vendors, these benefits are promised without the sort of complete, top-to-bottom explanation that we are providing in this book.

But even though SAP's vision is complete, nobody expects the fulfillment of that vision to be rapid or effortless. If Hasso Plattner could wave a magic wand and all of a sudden bring every enterprise service needed by SAP and all its customers into existence, what would be the result? How would this work? What would be the benefit for SAP and its customers?

Another way of thinking of this is to ask the question, "What will the world of enterprise software and IT be like in a completely enabled Enterprise Services Architecture?" Here's one vision.

The first major difference in the world of a complete Enterprise Services Architecture is in the nature of software requirements and documentation. Instead of having lengthy requirements documents that describe systems, a series of models would be used that would always be accurate because the applications would be generated from them. At the highest level would be models of the business showing the relationships among process components. Next, each process component would be modeled in terms of the enterprise services that would automate the business processes. The enterprise services themselves would be modeled from business objects. All of this modeling would be used to create service providers. Composite applications would be generated the same way from UI models, process models, and modeling to create business objects in the composites through service composition. Thanks to Plattner's magic wand, all of the services to enable all of this automation would exist in the repository.

Unfortunately, there is no magic wand, and instead, SAP and its customers and partners must gradually build the inventory of enterprise services, the repository to hold their descriptions, and the modeling and development tools to construct service providers and composite applications. The next question addresses how that is likely to play out.