The service-oriented architecture (SOA) methodology was created to accelerate and simplify the crucial task of bringing enterprise software applications to market. But what is an SOA - and is it still relevant today? This blog explores this subject and how it aligns with OutSystems modern application development platform.

What Is a Service-Oriented Architecture

A service-oriented architecture (SOA) is an approach to creating software applications that aims to promote reusability and business agility and to ensure that non-functional requirements (e.g. security, scalability and performance) are met.

Each component in an SOA performs one of three different roles: service providers create web services and provide relevant information to the service registry (or broker) so they can be subsequently discovered and re-used. The service requester locates the service it needs via the broker and binds with the service provider to invoke the functionality it requires.

How Did SOA Come About?

SOA emerged at the start of this century as a response to a prevailing IT environment where software development was unwieldy and slow – and was all-too-frequently delivered late and over-budget as a result. Not only that, but the resulting applications were highly interrelated and therefore hard to modify or upgrade: updates might have unintended (and negative) consequences to another part of the application and so implementing change involved a huge amount of testing and was glacially slow.

Instead of approaching application development as the creation of a single monolithic entity, SOA sought to break apart these monoliths into smaller, more manageable chunks – or services. In this context, services are not fully-fledged applications but components that can be combined in different ways to make those applications. The SOA provides a set of design principles that provide structure for the creation of these components and their aggregation into fully-featured applications.

What Is a Service?

There are many different definitions of a service but that from the Open Group is as good as any. According to them, a service:

  1. Represents a discrete business activity with a specified outcome.
  2. Is largely self-contained.
  3. Is a ‘black box’ for those that use it, meaning that there is no requirement to understand the service's inner workings.
  4. May include (or even consist entirely) of other services.

These services are generally loosely coupled and so largely independent of the other services in the application – meaning they can be modified easily without the ‘knock-on’ effects described above. The same service can also be reused if the same functionality is required by a different part of the application.

What Are the Benefits of a Service-Oriented Architecture?

The net effect of all of this is that SOA addresses many of the frustrations outlined earlier in this article. It drastically reduces the cost and complexity associated with enterprise software development. It also massively increases the speed with which new applications can be created and deployed – and existing ones upgraded. To the business, an SOA simply means that the IT department is far more responsive to their needs and the organization is significantly more agile as a result.

What’s the Difference Between Microservices and a Service-Oriented Architecture?

Microservices are cloud-native and are designed to bring extreme agility and to provide the most autonomous way to deliver software. The two approaches are similar and aim to promote the same reusability and agility but they do differ in scope: SOA looks at services in the context of the enterprise and their use in many different applications whereas microservices are focused on the architecture of the application itself.

In many ways, microservices can be seen as an evolution of SOA: although the latter already enforces a modular approach, microservices provide a number of different enhancements to this – but it is not a silver bullet and not every organization is equipped to provide a full-blown microservices architecture. To learn more about this topic, please refer to the Microservices Architecture in OutSystems documentation.

Does OutSystems Promote a Service-Oriented Architecture?

In a word, yes. OutSystems was created to address the problems associated with enterprise software development described earlier; and we share SOA’s ambitions of delivering greater agility, reusability and time to market. Like all SOA environments, OutSystems delivers applications that are functionally complete and which address non-functional requirements using services that are properly governed and easily discoverable.

How Does OutSystems Differ from Other Service-Oriented Architectures?

All Ferraris are cars, but it’s not the case that all cars are Ferraris! In the same way, while all the applications created by our customers are examples of an SOA, not all SOAs share the attributes of OutSystems. There are two key distinctions:

1. Platform Versus Toolkit

Most SOA vendors provide a set of tools and a structure with which to create services; but these are provided without any intellectual property, so all services have to be created using in-house intelligence. With OutSystems, business logic is included with each component in the platform, enhancing the speed with which applications can be created. Any changes to the component are automatically replicated in every instance where that component is used, so incremental adjustments to an application can be deployed in hours. Being a platform, OutSystems provides greater automation for service deployment, discovery, governance, and impact analysis on service changes, which are fundamental to achieve greater agility.

2. Visual Development Versus Object-Oriented

Most SOAs are object-oriented, meaning that every aspect of the architecture is represented as objects which are then used to build services. Working with objects is much quicker than coding from scratch but still requires extensive developer training. OutSystems provides a visual abstraction of the application so it can be built using a ‘drag and drop’ approach – with much of the repetitive work handled automatically in the background – an approach that promotes much greater developer productivity.

The use of visual programming also means that other people in the business are able to use OutSystems and that – at a time when developer resources are expensive and scarce – people without a coding background can become fluent in the development environment in only a few months.

To learn more about OutSystems application architecture, take a look at Application Architecture: Best Practices for Future-Proofing Your Apps.

And to dive even deeper into the world of OutSystems architecture, be sure you join us in our upcoming Tech Talk Head-to-head: Monolith vs. Microservices. On June 23, our team of experts will share all the best practices you need to know to define a modular and future-ready architecture. Don't miss!