Enterprise SOA

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 building—even if what you were building was ultimately redundant—than 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 ...