THE FUTURE OF ENTERPRISE ARCHITECTURES

A well-implemented enterprise architecture can truly be a source of competitive advantage, where the architecture itself supports both the immediate needs of today as well as the execution of a long-term business strategy. The ability to achieve this objective has historically been challenged by the limitations of the then-available technologies and architectures. These limitations have made it virtually impossible to maintain an enterprise architecture that meets both near-term and long-term demands. But can the implementation of an SOA help make these goals more achievable?

Competitive Advantage

Creating an enterprise architecture using SOA principles perhaps for the first time delivers the flexibility and agility necessary to make the enterprise architecture a realistic and achievable goal. Enterprise architectures implemented using SOA principles promise to deliver:

• Reuse —An architecture that delivers on the long-promised ability to reuse software. In the service-oriented world, we will see reusable services as opposed to the reuse of code.

• Flexibility and Agility —An architecture that is less fragile and more adaptive to ever-changing business pressures, either tactical or strategic.

Reuse Software reuse has always been a key part of component-based software models, but it has been a utopian goal that was rarely practical or achievable. SOAs implemented using Web services will completely change this dynamic as follows:

• Reuse from Legacy Systems —Early services will be implemented by reusing existing functionality in legacy systems. As discussed in Chapter 3, “Web Services Adoption,” the implementation of virtual services can be used as a basis for repackaging and repurposing legacy systems, greatly increasing their reach and longevity.

• Reuse of Business Services —Historically, reuse of components was especially challenging as they implemented fine-grained, low-level functions. An SOA implemented using Web services implements larger units of business logic as services, which if designed and implemented at an abstract level—specifically, not designed with a narrow, singleuse perspective—will be used by multiple applications across the organization. For example, the user management service, introduced in Figure 7.4, could be reused as the basis for a user administration service used for all systems in an organization.

The ability to reuse services, either custom developed or repurposed from legacy systems, will have a profound impact on time-to-market considerations. For example, imagine a situation where time to market for a new product is critical, but the IT infrastructure is the primary bottleneck, even though 70% of the necessary functionality is already implemented in other systems. Without an SOA, the organization would likely need to design and develop new systems to support the product from scratch, leveraging existing components where possible. Unfortunately, this is not going to help with time-to-market considerations, as it will likely take many months of elapsed time and require many person years of development time to implement the new system. Conversely, in an environment where systems are implemented as a collection of services in an SOA, the organization could analyze requirements for the new systems, choose existing services to provide 70% of the requirements, and implement the remaining 30% as new services. By reducing the design and development requirements by as much as 70%, the new application can be implemented in a fraction of the time and cost otherwise required.

Flexibility and Agility Traditional architectures implement “hard-wired” point-to-point connections between systems. This “hard-wired” approach makes systems extremely fragile and limits the options available to reconfigure an application without the need to manually change the hard-wired connections to other systems. In a complex environment, changing a single application can require the modification of dozens of connected applications.

For example, many large organizations run multiple ERP systems, perhaps using a best-of-breed approach to implement required functionality. If an organization runs PeopleSoft for its Human Resources (HR) function, but runs Oracle Financials for its general ledger and payroll functions, then PeopleSoft and Oracle will need to regularly share the information required to ensure that the payroll information is aligned with HR records—for example, are pay raises or cuts to be applied, are bonus or commissions payable, and so on. To link these systems together, a programmer must develop a custom interface tailored specifically to the proprietary application interfaces available from PeopleSoft and Oracle. A change to the Peoplesoft or Oracle application at either end of the custom interface—for example, one of the applications is upgraded—will typically necessitate that the custom interface be retested and perhaps updated. The problem is that a custom interface is limited to providing a hard-wired point-to-point connection that is fixed and inflexible. As the number of systems and their associated point-to-point interfaces proliferate, the integration of systems becomes a nightmare to manage.

In an SOA, it is possible to remove point-to-point connections and replace them with dynamic references using services descriptions, maintained in a services registry. As hard-wired interfaces are progressively replaced with dynamic references, the enterprise architecture becomes more flexible, enabling the following:

• Collaboration —The SOA supports more flexible collaboration, both among an organization’s own operating units and between the partner, supplier, and customer organizations. As illustrated in Figure 7.7, inhouse systems, as well as partner, supplier, and customer systems, all operate via the services registry, from which all of the organization’s services are accessible.

• Outsource —The SOA enables plug-and-play capabilities, making it much easier for organizations to outsource specific activities or processes when economically sound to do so. For example, as illustrated in Figure 7.7, by removing the hard-wired connections to the HR and Payroll systems, they can be easily and transparently outsourced, but continue to interoperate with in-house systems via the services registry.

  
  Figure 7.7: In-house or outsourced.

Fundamentally, the value of the enterprise architecture, implemented using SOA capabilities, is in enabling reuse and greater flexibility and enterprise agility. Once an SOA is implemented the enterprise architecture is no longer a “millstone” around an organization’s neck, but instead becomes a true foundation for strategic and competitive advantage.