Section 3.12. What kind of architecture skills does ESA call for?

3.12. What kind of architecture skills does ESA call for?

We won't delve too deeply into this question, as it will receive its own chapter (Chapter 7), but the fundamental challenges are worth noting here. The ESA universe of process-focused enterprise services, data objects, reusable components, and a platform composed of loosely coupled layers couldn't be more different from the current architecture of monolithic enterprise software and point-to-point, application-to-application integration.

Up until now, in its most pathological form, IT has developed a skill set and organizational framework that revolve around the construction of isolated applications to make up for the shortcomings of other older, isolated applications. It's a skill set that demanded a deep contextual understanding of legacy and enterprise applications, and it required small armies of in-house developers, third-party consultants from "best of breed" vendors or COBOL-coding specialists, and a mindset in which it was always, always better to build and keep buildingeven if what you were building was ultimately redundantthan to attempt to unwind the spaghetti of interdependent applications and hardware that had accumulated over time.

Now, contrast that with the skills needed for ESA, which begin with the disaggregation of the monoliths into the nuggets of enterprise services. ESA calls for carving out functionality, freeing it from context, wrapping and orchestrating services into fluid composites, and always, always seeking ways to separate the process logic from the integration logic and application logic and to reuse each as necessary. Whereas the previous generation of IT architects dealt only with all that was solid, ESA's architects are determined to make as much functionality as possible melt into air.

Before that can happen, IT must acquaint itself with an entirely new toolkit of application servers, portals, integration suites, Business Process Management tools, integration servers, and middleware before making any serious attempts to implement ESA on an enterprise-wide basis. A new backbone, or what Gartner called the "backplane," is proved acceptable only for small-scale, vanilla SOA implementations. "For performance, scalability or reliability reasons, other protocols than SOAP must be supported as well," Gartner warns. "Proper integration technology must be used to connect into legacy, non-web services-enabled applications. Dynamic discovery of services, routing of service invocations and mediation, or transformation of service interfaces are at times needed to enable flexible deployments in a distributed environment. Load-balancing, failover management, and other features are required to meet 'quality of service' requirements. Security and management must be enforced by means of externalized 'policies,' and a service registry must be implemented to enable services life cycle management. Tools to design and implement service interfaces and associated client 'proxies' must also be provided." Gartner predicts that by 2009, implementation of a sound SOA backplane will remain the single most important technical obstacle in SOA projects.^[*] Clearly, the time to begin retooling IT resources to build this backbone and to begin preparing for enterprise-wide deployment of ESA is now. And SAP is working on all fronts to help.

^[*] Gartner Presentation, "Applied SOA: Best Practices from the Best Practitioners," by Massimo Pezzini, October 2005.