This series of articles will describe a number of enterprise integration design principles, some based on Enterprise Services Bus (ESB) and Service Oriented Architecture (SOA) architectural principles, although can be applied to microservices and serverless architectures, in a more contemporary setting. These articles extract specific principles and applies them to technical solutions involving any system integration requirements.
Over the years, I have designed and implemented many aspects of traditional Service Oriented Architectures as well as having introduced Enterprise Service Bus designs to support robust, scalable and highly available integration solutions. The benefits of these approaches have included:
- Reusable and scalable components,
- Common frameworks and patterns for rapid service design and development,
- Model driven implementation for service abstractions, and
- Automated service and route discovery.
Future implementation and design should be augmented by flexible guidance to facilitate faster development objectives, and to align with current and future Enterprise design trends. The principals and patterns defined within this series of articles are intended to provide a flexible fabric for current and future IT solutions involving system integration.
My current thinking around an Enterprise view of integration comprises five distinct layers which are the basis for implementing integration principles.
The principal layers are:
- Stakeholders, customers and industry (users, devices)
- User Interface layer (information consumption)
- Business Process/Logic layer (information manipulation)
- Integration Services layer (information exposure/reconciliation)
- Data Services/Platform layer (information storage/discovery/analytics and maintenance)
Integration principles are expected to apply mainly within the Business Process/Logic and Services layers, but are not strictly limited to these layers.
The following architectural principles apply to all technology solutions which require any system integration functionality.
- Integration services perform the following activities:
- Data transformation,
- Data mapping,
- Abstract service endpoints from their source applications, and,
- Provide service orchestration,
- A business system, data store or application should almost always be abstracted by a defined interface,
- Integration services do not validate business rules or perform business validation on data. This is the role of specific business applications or an enterprise rules capability,
- Integration services may utilize a number of different protocols and technologies,
- Integration designs should always take into consideration:
- Support for rapid development/a high rate of change,
- Support and maintenance cost,
- Scalability and performance
In the next article, we’ll unpack the principles in more detail.