How does OutSystems fit in an enterprise architecture?
Table of contents
- OutSystems and the enterprise ecosystem
- Building services with OutSystems
- Service distribution over three levels
OutSystems fits perfectly in an enterprise ecosystem. Organizations can build a service-oriented architecture (SOA) that promotes service distribution over three levels: external API, core services, and integration services. Services can be tightly coupled in OutSystems applications to take advantage of the full capacity of the platform or completely decoupled in a microservices strategy for promoting CD/CI. As a result, organizations can easily update and permanently align their architecture with business strategy.
OutSystems and the enterprise ecosystem
After evolving over the years, an enterprise ecosystem usually consists of legacy systems and corporate databases from different vendors. Furthermore, these components exchange information and APIs with external systems, satellite apps, and web portals. The result is often a “spaghetti” 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 and too much business logic is placed in the ESB itself.
-
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 of its nature, OutSystems is the right choice for complex enterprise architecture. It enables organizations to address enterprise IT trends of composable apps, decoupling the front-end from the back-end, and abstracting reusable services and libraries. Libraries promote standardization and high reusability across applications. Services can be loosely coupled in a microservices architecture. Or they can be strongly coupled when monoliths are a better fit—for example, a scenario where all the consuming applications are in the same CD/CI pipeline—thus benefiting from single database transactions and avoiding the extra complexity of managing a distributed solution.
How are services supported? By providing visual modeling and the rapid creation of back-end services for either non-OutSystems consumers (exposing REST or SOAP APIs) or for other OutSystems consumers (either exposing strongly coupled actions or loosely coupled microservices). Organizations can innovate and differentiate while leaving the role of supporting the commodity functionality to slow-evolving legacy systems.
Libraries can be used for as connectors with external systems, UI patterns, common layout or application themes. Or bigger pieces of UI like Google Maps components.
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 like an ERP, a CRM, or corporate databases.
These services can be reused by OutSystems web or mobile 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 services with OutSystems
Building a service-oriented architecture 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 for designing a solution architecture
An OutSystems architecture design framework enables correct implementation and design. Four layers make designing SOAs simple. The framework 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 and without unmanageable dependencies, creating an architecture design that is easy to maintain and evolve.
Each layer in the framework addresses a different aspect of the functionality 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.
-
Defining the modules that implement the identified concepts, following recommended patterns.
Designing 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, enables the placement and movement of concepts in a digital framework for identifying and organizing all the architectural elements needed to implement a new project.
Three rules for a great architecture
To ensure that architecture is correctly abstracting reusable services, isolating end-user processes, and avoiding unmanageable references, organizations should follow these rules:
-
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 a 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.
The OutSystems architecture design framework takes care of the rule breakers. The Discovery tool automatically verifies compliance with the rules. It analyzes the actual dependencies between modules and identifies what actions, screens, entities, and other elements need to be corrected. Complexity is kept under control, saving time so more value-added tasks are the focus.
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 OutSystems and other applications are composed of core and foundation modules.
The OutSystems services can be exposed by SOAP web services or REST APIs, both of which are language-agnostic and easily consumed by other technology. For the internal consumption of services, OutSystems supports both loosely and strongly coupled services. With support for loosely coupled services, organizations can implement a microservice strategy with independent CD/CI pipelines. Support for strongly coupled services allows access to the full potential of the OutSystems platform where total independence between applications and services is not a requirement.
In both scenarios, OutSystems mechanisms are used to their full potential, namely performing impact analysis, searching for services inside the IDE, and managing security.
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 to minimize impacts from ecosystem changes. 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 and eventually adding some integration logging if required.
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.
Integration services
If the core service extends an external system of record, 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.