ESA Begins with IT Culture Change

By Sam Sliman
President, Optimal Solutions Integration, Inc.

In recent years, enterprise services architecture (ESA) or, as it is known in mainstream industry parlance, service-oriented-architecture (SOA) has transformed from a buzz term into a foremost business imperative, particularly among large enterprises with global operations. According to a recent report by Forrester Research, over 70% of companies with more than 20,000 employees are adopting SOAs. In a similar vein, a recent survey of 473 enterprise buyers by the Yankee Group revealed that 75% plan on investing in the technology and staffing necessary to enable a service-oriented architecture. Rounding out the analysts’ take the rapidly emerging SOA trend, Gartner predicts that by 2006, more than 60 percent of enterprises will consider SOA a guiding principle in designing their new mission-critical business applications and business processes. In addition, in that same timeframe, more than 75 percent of midsize and large enterprises will have deployed SOA-enabled development tools and middleware.

At the conceptual level, ESA is fairly well understood—break monolithic applications into reusable, discrete ‘enterprise services’ which reside on the network and can quickly and cost-effectively be drawn upon to build loosely couple applications that satisfy immediate business needs. The business benefits of an ESA also are well understood—seamlessly integrate a heterogeneous IT environment, increase business agility and flexibility, and reduce the total cost of ownership of past and future technology investments.

Ostensibly, ESA marks the end of rigid, monolithic enterprise apps and ushers in a new era of dynamic service-based business solutions that are adaptable and flexible, providing a more efficient way to keep up with rapidly changing business requirements.

But while there seems to be general consensus and agreement on what ESA means at the conceptual level and a good deal of business-speak regarding the potential benefits of ESA, there is much confusion and uncertainty on how best to develop and execute an overarching ESA strategy, and little-to-no practical knowledge of how an organization might identify specific IT initiatives and/or business processes well suited to serve as the launching point for an incremental transformation to ESA. Despite the simplicity of the ESA concept, building an enterprise ESA poses a significant technical and business challenge, and for many businesses, the critical first steps of an ESA journey have proven elusive.

Start by changing the IT culture

To embrace ESA in a manner that transcends rhetoric and truly prepares a business for the paradigm shift ESA represents, a fundamental transformation is required both in the way IT is perceived within the enterprise and in the way IT staff communicate with the business side of an enterprise.

The traditional perception of IT as a cost center must evolve to an understanding and appreciation of IT as a strategic resource vital to reducing costs, streamlining operations and gaining a competitive edge. And IT’s traditional application- or data-centric focus, where architects and developers work designing systems and building software for targeted business areas and with specific applications in mind, must give way to a business-process focus where IT initiatives are informed by a holistic, enterprise-wide perspective and driven by clearly defined business needs, with the clear-cut objective of improving an existing or creating a new business process.

ESA is not a technology in its own right, though it takes full advantage of technologies such as XML, UDDI, SOAP, WSDL, and Java-based messaging. ESA is really a new mindset and architectural approach for coping with the need for flexibility in enterprise application architectures. At its core, an enterprise services architecture is a distributed software model that uses independent Web services (enterprise services) to support business processes. As such, ESA compels architects and developers to focus not on application development in the traditional sense, but rather on building reusable enterprise services and then assembling those services into composite applications that implement a business process.

ESA also requires a shift away from a client/server approach to application development to thinking about event-driven interactions. Because services can and will be inserted anywhere within a business process, architects and developers must take a broader view of application development. The main difference is in how interfaces are crafted. In an ESA, the key is to develop interfaces that are coarse-grained and not based upon the application's component architecture. Application development, integration, and reuse in the context of an ESA dovetails with other disciplines such as business process modeling, workflow, and program-to-program communication.

Lastly, ESA involves incorporating service-oriented modeling concepts that affect both the technical and business process aspects of an automated business solution. The stakeholders in an ESA initiative can include executive management, IT management, project managers, developers, analysts, and business people both inside and outside of the company. To be sure, realizing the promise of ESA requires unprecedented collaboration between business managers and the IT team, and a thorough reorientation of IT away from hard coding point-to-point integrations and toward line-of-business issues, challenges and opportunities.