- Agony Versus Agility
- Enterprise Software Is a Different Animal
- The Importance of Enterprise Software Architectures
- The Requirements for an Enterprise Software Architecture
- The Relation of Enterprise Architecture and Enterprise Standards
- Organizational Aspects
- Lifelong Learning
- The Enterprise IT Renovation Roadmap
This chapter is from the book
This chapter is from the book
This chapter is from the book
1.5 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. There are a variety of different reasons for the failure of these EDM projects, including political turf wars between different departments, conflicting interests between the different stakeholders ranging from business representatives over application specialists to DBMS administrators, the sheer technical complexity of the undertaking, and the fact that due to the dynamics and complexity of modern enterprises, it is usually impossible to capture a snapshot of the complete state of the enterprise at a given point in time.
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 many cases, middleware such as CORBA was only used to solve point-to-point integration problems on a per-project basis, instead of being established as a global software bus; as a result, many enterprises now have nearly as many incompatible middleware systems as they have applications.
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 middleware—ranging from DCE over CORBA to SOAP and WSDL—have 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 a book 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 WSDL—while maybe technically superior and more flexible—going 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 book 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 book. 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. They enable the structuring of application components on the local level while also catering for global integration of these components. As we will show in this book, an SOA does not rely on the support of particular runtime protocols, such as SOAP or IIOP. Therefore, an SOA does not impose adherence to technical standards on the global level and is not based on strict norms and specifications (see Figure 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.
Applications that are structured according to the guiding SOA principles laid out in this book will be able to fit into any integration scenario, regardless of the runtime protocols required. Having said this, work will still be required to bridge technology gaps, such as different communication protocols, but the efforts required to bridge these gaps will be marginal when compared to the complexity of integrating applications on the structural level.