Section 4.4. What are the architectural challenges of ESA?

4.4. What are the architectural challenges of ESA?

The architectural challenges of ESA stem from the violation of the implicit assumptions referenced earlier; the ideas of the database as a point of integration and the application as a process boundary no longer apply.

The first challenge is flexibility . Once services are created and processes are automated, optimization and innovation depend on a company's ability to not only implement processes, but also be able to change and improve them based on experience. This is a huge challenge, considering the average optimization cycle of today's custom application projects, which may range anywhere from 9 to 18 monthsa timeframe that is no longer acceptable. Companies need to implement a new IT system within weeks and months in order for it to have an impact. The tradeoff for flexibility has traditionally been costit's easier to make changes to a system when development costs are no object. But that implies the system was never very flexible in the first place. Inherent flexibility implies a corresponding reduction in cost to make changes because flexibility has to be affordable in order to be meaningful.

The second challenge facing ESA is data consistency how to unify and synchronize all of the information and process flow in an automated process where data is stored in lots of different databases and lots of applications are supplying services.

The third challenge is heterogeneity . The modern enterprise can't assume that all of its software and systems will always come from a single vendor. A heterogeneous computing environment is a given in today's world. In fact, it is inevitable. Even if management consciously set out to choose a single vendor, mergers and acquisitions make it inevitable that systems from a different vendor will arrive with some acquisition down the road. And even if the company is an island, homegrown applications or specialized tools from a niche vendor will ultimately introduce complexity at some point.

The fourth challenge is the user interface (UI) . Now that companies have the ability with ESA to combine and recombine enterprise services in any manner they wish, designing the most efficient and the most appropriate interfaces for the delivery of the right functionality to the right person becomes extremely important. As processes are developed, roles must be developed in tandem for the employees charged with collecting information, evaluating that information, and making a decision based on that analysis. But what data, presented in what form and at what level of aggregation, is appropriate for each person in that chain? Torrents of data may be flowing from any given business process, but to be efficient, each role that plays a part in that process needs that data reduced to the level at which people in that role can best perform their appointed tasks. Previous generations of enterprise applications had been built as reflections of the database's internal structure rather than as reflections of the roles people play in the application's process. In practice, this meant that performing a simple, real-world task required using 4, 5, 10, or even 15 UIs reflecting different aspects of the database structure instead of accessing a single screen specifically created so that that person could perform his task. The UI challenge is one of bringing together and making affordable the creation of many role-based interfaces for the convenience of human users.

All of these challenges point to a tremendous impact and change in IT development. The need for inexpensive flexibility, along with the demand for customized interfaces throughout the organization, implies that development must become cheaper and faster in a hurry. That will require the demystification of IT. Development must become simple enough so that not only will highly trained programmers and information architects build and deploy services, but managers outside of IT will as well. SAP has envisioned the role of the business analyst, a manager versed in IT but lacking traditional development skills, though she has a much deeper understanding of the actual business processes being automated than the developers in IT do. While IT focuses on exposing services and maintaining the architecture, business analysts will receive the tools to create the necessary applications and interfaces to extend process automation even further.

At this point, the gap between IT and the business will be bridged. IT will supply the business side with those tools, and the resulting conversationabout how to create those interfaces and automate those processeswill replace the lengthy, inefficient negotiations in which the business side explains what it needs to IT, which tries to figure it out and then returns with a requirement spec. And so the traditional dance would have gone on, except that within ESA, the use of services and modeling tools creates a very unconventional development environment.