␡
- 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
This chapter is from the book
1.4 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, an 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. Many IT coordinators will have detailed business domain knowledge but no technical expertise. On the other hand, technical architects will probably have an excellent technical education but have little understanding of the vertical business. Nevertheless, all the people involved must be able to understand and manage the architecture at their respective levels (e.g., specifying new functionality at the business level and implementing and maintaining it).
- 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. To a great extent, interfaces must be generic and not specific to a single usage scenario. However, defining generic interfaces requires excellent domain knowledge, experience, and to some extent, luck. Finally, the internal implementation of a component must allow efficient maintenance, making it is easy to add or modify functionality.
- 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. However, perhaps a more important aspect of reusability is the ability to share data across applications in real-time, thus reducing content redundancies. Having to maintain the same dataset in multiple databases becomes a nightmare in the long term. Unfortunately, it is not easy to achieve the goals of reuse. Large organizations have learned that reuse is not always efficient because it is particularly costly to administer, find, and understand the components that should be reused, and sometimes this cost outweighs the benefits.
- 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. It is therefore a major requirement that the architecture tolerate both heterogeneity and change to its technical infrastructure. Furthermore, the development of business functionality must be decoupled from the underlying technology. In particular, the architecture must avoid dependencies on specific products and vendors.
This book illustrates how a Service-Oriented Architecture can help achieve the design goals for enterprise software systems as described previously.