- 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
1.2 Enterprise Software Is a Different Animal
In order to better understand the problems of enterprise software, we need to look at the specific characteristics of it, which are different from those of other types of software, such as system software, desktop applications, embedded systems, scientific software, or video games.
As the name indicates, enterprise software is tightly coupled with the internal organization, processes, and business model of the enterprise. Enterprise software underlies both cross-departmental dependencies and external business relationships. Consequently, an architecture for enterprise software must deal with large numbers of different requirements. Many of these requirements are conflicting, while others are unclear. In almost every case, the requirements are a moving target due to the permanent change of markets, the organization of the enterprise, and its business objectives. It is this involvement in all aspects of the enterprise and the business that makes enterprise software highly complex.
Enterprise applications rarely contain a large amount of complicated algorithms. The code that describes a piece of business logic is usually very simple. The structure of a COBOL-based billing system is much simpler than, for example, an embedded system for a Mars robot with complex real-time and multi-threading requirements. In enterprise applications, one usually finds very simple data structures, which again are different from other systems such as geographic information systems (GIS).
Let's consider an example in order to illustrate the difference between enterprise applications and other software: An enterprise application such as a Customer Relationship Management System (CRM), a billing system, a shipping system, or an insurance claims processing system. The stakeholders in these systems include different business units and potentially even the CEO, as well as different IT projects, IT maintenance, and operations. In these scenarios, we will be facing highly heterogeneous teams and often very political environments. The technology landscape will be highly heterogeneous as well, including many different application and middleware platforms. The business data and content will have a very long lifetime, especially when compared with the much shorter cycles of technology innovation. We need to deal with constantly changing functional requirements that are usually not well-defined. In addition, we will be facing many cross-dependencies between functional requirements, as well as heterogeneous technology platforms. The number of end users will be potentially very large, and the applications will have to be rolled out to large numbers of PCs, often more than 10,000.
Take, on the other hand, a desktop application, such as a word processor or spreadsheet application. A smaller, more homogeneous technical team will develop this application. It will be used by office workers as well, but the problem space is more well-defined. The application logic is self-contained, with very few cross-dependencies. Finally, there is no roll-out problem because the end user is typically responsible for the installation himself.
As we can see from these examples, enterprise software is unique in many respects, and therefore, it requires unique measures to ensure the efficiency of its development and maintenance.