A New Style Is Emerging in the Enterprise: Software-Defined Architecture

| by Abel Avram Follow 9 Followers on May 24, 2014. Estimated reading time: 3 minutes |

According to Gartner’s Yefim V. Natis, VP & Fellow, a new enterprise architectural style is rising these days: Software-Defined Architecture (SDA).

During the Gartner webinar entitled Software-Defined Architecture: Application Design for Digital Business (account required), Natis took a look at the challenges that modern IT presents to software architects and some of the design principles that help architects create better applications that last longer. Among other things discussed during this webinar, Natis introduced this idea of SDA as a natural development in software architecture following previous styles starting with the monolithic one of the 70s as depicted in the next graphic taken from the webinar’s slides (PDF):


SDA follows on the path of Software-defined Networking (SDN), Software-defined Storage (SDS), and others, introduced by cloud computing, but this time it applies to whole stacks of software. The main idea is to introduce a level of virtualization between software producers and consumers. This boundary hides the internal details of a certain implementation, making it possible to change or replace the implementation without affecting the consumer. This process leads to the creation of two sets of APIs: an internal one for the producer’s use and an external one for the consumer as seen in the above graphic.

While the Inner API expresses a system’s organization in easily maintainable modules following standard architectural principles and comes on top of system optimizations for performance, the purpose of the Outer API is to make the Inner API easily and safely consumable by various external entities. Outer APIs offer a simplified view of the system and are optimized for network calls initiated over long distances.

To create SDA one starts with services, but they are not to be consumed directly. Instead, a gateway separates the services from consumers, creating a virtualization boundary between the two, as shown below:


SDA Gateway is responsible for the process of virtualizing the internal implementation resulting in the translation of the Inner APIs, the protocols and models used. This includes dealing with API versioning. The gateway covers a number of other functions such as security, routing, orchestration, etc. According to Natis, currently such a gateway is partially implemented by several products such as API Managers from Apigee and Mashery, API Gateway from Layer 7 or Vordel, ESBs that have expanded to include API management, and IPaaS (Integration Platform-as-a-Service) such as CastIron or Boomi.

Natis also recommends dealing with data security by creating a small number of services allowed to interact with raw data, thus concentrating the management and security to a smaller set of APIs reducing the footprint of possible security breaches.

We have interviewed Natis to find out a few more details on SDA.

InfoQ: I have not heard of SDA until now. Has this term been used by someone or have you coined it?

[YN] Yes, Gartner is introducing the term Software-defined Architecture.  It’s new and we have not yet published reports on it.  It’s underway.

InfoQ: Is SDA a natural step in the progress of software architecture from monolithic, 2-tier, etc.?

[YN] Yes, you can see SDA as virtualized or managed SOA.  It’s a response to the proliferation of SOA interfaces (APIs) and continuing demand for more user-defined APIs. With SDA applications are virtualized and the outer APIs become decoupled from the inner APIs, allowing free creation of custom outer APIs without loss of application control.

InfoQ: What are the benefits of using SDA?

[YN] Virtualization of applications and application services; introduction of an intermediary (Gateway) between the outside world and the applications; an opportunity to add management, tracking, security, charging, activity monitoring, optimization, routing, integration, composition , orchestration, context injection and a lot of other added value between the external consumer of services and the applications that implement these services. One special possibility is to allow consumers to design their own APIs without adding risk to the underlying applications and data.

InfoQ: Could you provide some examples where SDA is being used?

[YN] SDA for applications is a new concept and there are not many significant implementations. Netflix API management is one proprietary example.  But many uses in mainstream enterprises of integration brokers, API managers and API Gateways as well as SOA interface managers provide some degree of SDA capability.  A full-fledged consistent use of SDA in application services management is several years away. It depends on technology, but no less – on the culture and discipline of the organizations that implement it.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Service facade pattern? by Christian Schneider

I think this is not much more than the Service Facade pattern. The only difference is that there is also an inner service. I have seen this since at least 5 years for example to have technical services inside and more business like services for the outside. So where is this a new paradigm?

Re: Service facade pattern? by Abel Avram

The service facade is a simple pattern that does API translation. Besides that, SDA includes a Gateway incorporating massive amounts of related services as described in the article.

Re: Service facade pattern? by Abel Avram

I post the following comment on behalf of Yefim Natis, the Gartner webinar author mentioned above:

As the saying goes, “Future is already here, but it is not distributed evenly”. Some implementations of ESBs or BPMS have had the “front” APIs separate from the inner APIs for years. But it was not recognized as architecture. Some architects long recognized the need to virtualize the outer layer of application APIs for years too. But majority of mainstream applications using SOA did not implement the fundamental notion of SDA (as applied to application services, better referred to as SDAS): The outer APIs are virtual. They do not have service implementations behind them. Instead, they lead to the intermediary (an SDA Gateway) which translates the virtual APIs to some arrangement of “real”/”physical” inner APIs that indeed do lead to service implementations and ultimately to data. Years ago we called these virtual APIs “pseudo-services”. It then applied to wrapping legacy applications using screen-scraping or whatever was necessary). Virtual APIs are light-weight. They are easy to create and tear down without exposing the application to security, performance or integrity risk. And in addition, once there is the intermediary – a lot of added value can be introduced to add tracking and billing, context injection, scalability and the most intriguing – ad-hoc development of virtual APIs by the users to meet user requirements and support rapid innovation.

Re: Service facade pattern? by Christian Schneider

Got it. So the main new thing is to have a gateway with rapid development functionality to easily create new outer services. I am not sure though how feasible this is. You mention that the advantage is that the outer services can be easily created an torn down. The problem I see here is that you never can easily tear down an API. APIs are long lived with a lot of emphasize on compatibility and management of the API. The only way I see to make them easy to change is to not publish them and instead only use them for one consumer. Is this what you intend?

Re: Service facade pattern? by Abel Avram

I don't remember saying that the Outer API is to be "easily created and torn down." I said
... the Outer API is to make the Inner API easily and safely consumable by various external entities. Outer APIs offer a simplified view of the system and are optimized for network calls initiated over long distances.

and also
This boundary hides the internal details of a certain implementation, making it possible to change or replace the implementation without affecting the consumer.

which seems to me doable and desirable. What can be easily torn down is the inner implementation which is hidden to customers.

SOA and Software Defined Architecture by Adrian Grigoriu

To start with, the concept was since long called SDP (Service Delivery Platform) in the telecoms world. With SDP, the telecoms provided external customer applications APIs to internal services such as location, presence, calls, data connections... It existed even before that, in fact. The layer or gateway provided access control, QoS and security as well.
But SDP was, in fact, a tad more than that.

The concept already exists in SOA as well, where, for instance, mainframe interfaces are wrapped in SOA APIs. It is usually employed to hide existing applications interfaces under SOA APIs.

The reader should understand though that most SW manufacturers have adopted the SOA paradigm. And many are working to expose their services in the Cloud through simple APIs.

The problem is that the more public are the interfaces the more standardised they should be. Standardisation is what we need before using such interfaces. But then the Cloud growth may see to that.

For the time being, Cloud Brokers introduce a link in the services value chain to provide a uniform approach and the integration of Cloud Services. They do not call themselves SDAs providers though. And they introduce costs, delays...

The approach might be, rather than a physical gateway, a Cloud integration management suite, with which Cloud applications are compatible. This no SDA though.

Hence, there is nothing new here, except perhaps the term, SDA. But Gartner excels at new terms.

Article Review by Stephane Castellani

Thanks for this very interesting article and for sharing vision in an always changing environment where strategic decisions need to be made for the next years. Btw, please note Vordel was acquired by Axway end 2012 and that the product is now called "Axway API Gateway"

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

7 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you