OutSystems fits perfectly in an enterprise ecosystem. Organizations can take advantage of the full potential of the platform to build a service-oriented architecture (SOA) that promotes service distribution over three levels: external API, core services, and integration services. This enables organizations to easily update and permanently align their architecture with business strategy.
OutSystems and the enterprise ecosystem
After some years of evolution, an enterprise ecosystem usually consists of legacy systems and corporate databases from different vendors and technologies. Furthermore, these components exchange information and APIs with external systems, satellite apps, and web portals. The result is often a spaghetti-like architecture that makes it difficult to maintain and evolve digital support for an organization's business strategy.
The main issues that surface are:
Poor service abstraction: Services for core business concepts are not correctly isolated and abstracted. Business rules are spread over different systems and code reuse has very little structure.
Unmanageable system dependencies: Systems are not correctly isolated from each other so updating or replacing a system has a snowball effect on other systems. Having an enterprise service bus (ESB) to unify the communication between different systems helps. However, it cannot ensure system independence if the representation of business concepts is not properly normalized.
Inflexible, slow-moving legacy systems: Quickly adapting a legacy system to business changes is difficult. If the system is complex and inflexible, changes can take a long time. Sometimes the technology is obsolete. And, the accumulation of core information and system dependencies over time can hinder any replacement.
Because it is an open platform, OutSystems is the right choice for a complex enterprise architecture. It enables organizations to address the enterprise IT trends of composable apps, decoupling the front-end from the back-end, and abstracting loosely coupled services. How? By providing visual modeling and the rapid creation of back-end services for REST and SOAP consumption, both inside and outside OutSystems. Organizations can innovate and differentiate while leaving the role of supporting the commodity functionality to slow-evolving legacy systems.
Typically, OutSystems is positioned in an enterprise ecosystem as illustrated by the following diagram.
A set of OutSystems services provides core functionality that is either fully implemented in OutSystems or that extends and normalizes functionality from external systems or records. Examples of the latter are external producers and corporate databases.
These services can be reused by OutSystems applications and microsites, which are small web applications that run in an iFrame of another website. They can also be used by external consumers, external portals and other applications not developed with OutSystems.
Building an SOA with OutSystems
To build a service-oriented architecture (SOA) that powers the constant digital revolution of a modern enterprise, following sound architecture principles, is important. These principles ensure that OutSystems is correctly implemented in the surrounding ecosystem and value-added services are properly designed.
A framework to design a solution architecture
An OutSystems architecture design framework enables correct implementation and design. It uses four layers to make designing SOAs simple. It promotes the correct abstraction of reusable services and the correct isolation of distinct functional modules. The result is a set of modules with more independent lifecycles without unmanageable dependencies, which creates a cost-effective architecture design that is easy to maintain and evolve.
Each layer in the framework sets a different nature of the functionality to be captured in a module:
This framework is used in two different stages of architecture design:
Identifying concepts, such as functional, non-functional and integration needs. The framework collects architecture requirements systematically and with structure.
2. Defining the modules that implement the identified concepts are designed by following recommended patterns.
Designing an architecture is not a one-time event. It is a continuous process. The architecture must be iterated by cycling through these two stages as a solution evolves and new concepts and needs emerge from the business.
The Electronic Canvas tool, which is available in OutSystems Forge, can assist with the design of a new architecture. It enables the placement and movement of concepts in a digital framework to identify and organize all the architectural elements needed to implement a new project.
Three rules for a great architecture
Three rules must be followed to ensure that architecture is correctly abstracting reusable services, isolating end-user processes and avoiding unmanageable references:
No upward references: An upward reference indicates that services are not isolated at the correct layer. These references are the major cause for complex unmanageable dependencies that can evolve into huge clusters of modules in direct or indirect cycles.
No side references for orchestration or end-users: Orchestration and end-user modules should not provide reusable services. This ensures that they are correctly isolated and don't interfere with each other's lifecycles.
No cycles between services: Conceptually, a service normally depends on or extends another service. A cycle typically shows that the concepts are not correctly isolated. For example, there are misplaced elements. Or it indicates that there is the need to isolate a third, and more general, concept that depends on the others.
Verifying these rules in a complex system and running these checks as the system rapidly evolves can be difficult. Automated mechanisms can help.
A major advantage of the OutSystems architecture design framework is how easily it enables the identification of architecture violations so they can be corrected. Compliance with architecture rules in an OutSystems environment can be automatically verified with the Discovery tool. This tool analyzes the actual dependencies between modules. It enables the easy identification of violations of these rules and the actions, screens, entities and other elements that are incorrectly assembled. Complexity is kept under control, saving time and enabling a focus on value-added tasks.
Services as the core of enterprise architecture
The principles of the architectural design framework are the key to guiding the design of an OutSystems solution, and correctly integrating it into an enterprise ecosystem. Applying these principles enables a clear separation of services and applications. OutSystems applications and microsites are primarily composed of end-user and orchestration modules. The services that support both OutSystems and other applications are composed of core and library modules.
The OutSystems services can be exposed with SOAP web services or REST APIs, both of which are language-agnostic and promote loosely coupled services that can be consumed internally. OutSystems applications use these services directly to exploit the full potential of the OutSystems platform. As a result:
Entities and reusable UI widgets are consumed.
OutSystems mechanisms are used to their full potential.
Calls are more efficient; there is no web service marshaling/unmarshaling.
Service distribution over three levels
This service architecture example shows how OutSystems promotes service distribution over three levels: external API, core services and integration services.
OutSystems makes it easy to apply these principles so core services are correctly isolated from external systems and ecosystem changes have minimal impact. Ideally, only the external API is affected when an external consumer is changed, added or removed, while the same actions for an external producer affect only integration services.
External API level
The composition of APIs that expose services to external consumers occurs at this level with REST, SOAP or others. No business logic is added. This level is a technical wrapper for the real services implemented in the core services layer, translating those services to the APIs agreed with external systems.
Core services level
Implementation of the service itself occurs at this level with all the business rules and core entities. Core services should be system-agnostic.
If the core service extends an external system of records, the integration is abstracted by an integration services layer. This layer is simply a technical wrapper for normalizing data structures and abstracting integration complexity, such as recovering from errors and authentication for external systems.