According to the second law of thermodynamics, any closed system cannot increase its internal order by itself. In fact, any activity that is geared toward ordering the system will increase its overall disorder (called entropy). In many respects, this law is also applicable to enterprise software, which often has very similar characteristics. Consequently, outside intervention is continually required to help create a higher order and to ensure that development efforts are not lost.
In enterprise software, the architect takes on the role as an outside influencer and controller. It is his responsibility to oversee individual software projects from the strategic point of view of the overall organization, as well as from the tactical, goal-oriented viewpoint of the individual project. He has to balance different requirements while attempting to create an enduring order within the enterprise software landscape. The enterprise software architecture is the architect's most important tool at hand. Software architects are constantly confronted with changes to and expansion of functionality that increase system complexity and reduce efficiency. By refactoring current solutions, architects constantly strive to reduce complexity and thereby increase the agility of the system (see Figure1-2).
Figure 1-2. Software architects use refactoring to fight the constant increase in system complexity.
Apart from the events that increase complexity during normal usage of the architecture, single events can also have an important effect on enterprise IT. They might occur in major changes to existing jurisdiction, the end-of-life of a supported product, or the introduction of large chunks of computing infrastructure, such as in the course of a merger or acquisition. Such events require a major effort at very short notice to keep the architecture in a simple and maintainable state. As we will see in the remainder of this article, Service-Oriented Architectures are particular well suited to cope with the needs of such an ongoing incremental process of optimization.
The Requirements for an Enterprise Software Architecture
As a result of the aforementioned tight coupling with the internal organization, processes, and business model of the enterprise, an enterprise software architecture must fulfill very different requirements than, for example, a software architecture for a system that is controlled by a small number of highly qualified domain experts, such as the Mars robot or a video game engine.
In order to improve agility and efficiency, enterprise software architecture must provide particular characteristics:
Simplicity. The enterprise architecture must be simple in order to allow efficient communication between key personnel. As previously discussed, many people are involved in the specification and construction of enterprise software. All these people have different roles and consequently different viewpoints with regard to the software. It is also likely that several different skill sets exist among personnel. These might range from IT coordinators of functional departments to technical architects.
Flexibility and maintainability. Every enterprise system is subject to ongoing change. It must continuously be adapted to new requirements due to the need of evolving markets, legal changes, or business reorganizations. Therefore, the architecture must lead to a highly flexible and maintainable system. The architecture must define distinct components that can be rearranged and reconfigured in a flexible manner. Local changes cannot be permitted to have an impact on the global system. Providing that the external API of a component remains stable, an internal change should not affect operations outside the component. In this context, one needs to understand that external interfaces of components must be designed very carefully.
Reusability. Reusability has been a major objective of software engineering for decades, with varying degrees of success. It is in the interest of an enterprise to gain as much benefit from its software assets as possible. This can be achieved by creating an inventory of useful building blocks and continually reusing them. One obvious reason for reuse is reduced development and maintenance cost, which can be accomplished by sharing common functionality in code libraries that are used across different projects.
Decoupling of functionality and technology. The architecture must make an enterprise organization independent of the technology. It must decouple the long lifecycle of the business application landscape from the shorter innovation cycles of the underlying technology. Moreover, an architecture that is designed to last longer than one or two of these technology innovation cycles must cope not only with changing technologies but also with the actual lifecycles of installed technologies, which can be much longer. This article illustrates how a Service-Oriented Architecture can help achieve the design goals for enterprise software systems as described previously.
The Relation of Enterprise Architecture and Enterprise Standards
For many decades, enterprise IT organizations have attempted to improve agility and efficiency by homogenizing their systems through the introduction of enterprise-wide IT standards, but mostly with very limited success. Therefore, it is important to understand that an enterprise architecture is not equal to an enterprise standard, as we discuss in this section.
In the 1980s, with relational database systems becoming mainstream, we saw a wave of so-called Enterprise Data Model (EDM) projects. The idea of these standardization projects was to define one global data model for all the business entities in an enterprise, which was to be shared among all the different organizations and systems in a company. Almost all of these EDM projects failed, and today, there are usually as many different database schemas out there as there are databases in an enterprise. In the 1990s, we saw the next attempt to homogenize the enterprise application landscape, this time through enterprise-wide middleware standards. The concept of the Enterprise Software Bus became popular. The idea was that by agreeing on a ubiquitous, technology-independent, enterprise-wide standard for communication between software modules, the problem of application integration would be solved once and for all. However, the reality in almost all enterprises today is that in addition to application heterogeneity, we now face the problem of middleware heterogeneity as well.
In general, it seems fair to say that enterprise standardization efforts in IT have failed to deliver on their promise of homogenization and easy application integration. Too many generations of middlewareranging from DCE over CORBA to SOAP and WSDLhave been touted as silver bullets but have failed to become established as the ubiquitous Enterprise Software Bus, leaving behind a high level of cynicism among the people involved. As a reader of this article on Service-Oriented Architectures, you might now be asking yourself, "So what is different this time?" Is SOA not yet another enterprise-wide standardization effort, this time under the label of the Enterprise Software Bus? How are SOAP and WSDLwhile maybe technically superior and more flexiblegoing to address the organizational challenges of global standards that made the Enterprise Data Model, the Enterprise Software Bus, and many other enterprise standardization efforts fail to a large extent?
This article takes the position that SOA is neither a technology nor a technology standard, but instead it represents a technology-independent, high-level concept that provides architectural blueprints, such as the ones outlined in the first part of this article. These architectural blueprints are focusing on the slicing, dicing, and composition of the enterprise application layer in a way that the components that are created and exposed as services in the SOA are not only technically independent but also have a direct relationship to business functionality. Therefore, an SOA does not impose adherence to technical standards on the global level and is not based on strict norms and specifications (see Fig 1-3).
Figure 1-3. Enterprise Data Models and Software Buses were popular approaches to the challenges of enterprise computing in the 1980s and 1990s.
References:
Enterprise SOA: Service-Oriented Architecture Best Practices
By Dirk Krafzig, Karl Banke, Dirk Slama