SoaScape has been developed to facilitate management of API’s (web-services) and application-to-application interconnections. The product provides for the following needs:

• Centralized registry of API’s and application interconnections across diversified technologies and hybrid environments (Cloud and in-house). As much as possible, the information about interconnections is retrieved from intermediaries such as SOA/API Gateways; this capability minimizes the administrative burden of keeping information up to date.
• Insights into application interconnections of the entire application landscape, covering concerns ranging from operations to strategy. This is achieved by providing the ability to navigate intuitively through the information stored in SoaScape, high-quality visualizations, a variety of reports and with the capability of exporting data to Enterprise Architecture Tools and Excel.

The distinctive value of SoaScape is that the administration and management of API’s and application interconnections can be accomplished with a very minimal effort.

The underlying premise is that API’s and interconnections are being centrally registered. This implies that a successful implementation of SoaScape depends on whether this need is understood and whether the responsibility of keeping the SoaScape information accurate is adequately assigned. In that respect, what holds for any other similar product also holds for SoaScape: the management of application interconnections has to be a part of organization’s IT policies and procedures.

In Gartner terminology, SoaScape falls into the category of API Management products.

Why Registering Application Interconnections Matters?

What is certain is that larger organizations use many API’s and that this usage is growing. Moreover, several IT trends are bringing new challenges to this domain, namely:

• More application interconnections across organizational boundaries
• Service exposures to mobile devices
• “Open Data”
• Microservices
• Mixed application deployments (on premise, PaaS, IaaS, SaaS, etc.)

These trends are the continuation of those set by Service Oriented Architecture which became the mainstream. SOA is not something we talk about anymore; we just practice it. Thanks to SOA (backed by solid web services technologies), IT solutions have gained in strength and flexibility. Advancements such as enabling access to shared data across an organization, providing online services to partner organizations, exposing data and functions to mobile applications or facilitating multi-channeling by exposing back-office services to the front-office are all possible due to service orientation. In short, the business functionality is provided by multiple software components that interact without human assitance.

On the one hand, technology simplifies greatly the way we establish and manage individual interconnections; on the other, dependencies proliferate and the overall complexity increases. Applications use services provided by other applications and cannot fully perform their tasks unless the services they use are also functioning. This functional dependency has become an essential aspect of the way in which organizations work.

Modern business processes therefore depend not only on the functioning of each individual application involved but also on interconnections between them. Hence, organizations need to view their applications as an integrated whole and give appropriate attention to the management of application interconnections. Otherwise one cannot responsibly deal with issues associated with interdependencies between applications which also, last but not least, include continuity and security risks. The issues can be best illustrated by way of some examples. We should ask ourselves whether we know:

• How many API connections exist, and can they all be audited (performance, reliability, security, etc.)?
• What are the consequences of an application’s failure for the rest of the application landscape, and which business processes are being affected? What are the dependency chains?
• What is the dependency of my organization on services provided by other organizations and vice versa? Which of my organization’s services are exposed to consuming applications over which I have no control?
• Is the use of services by mobile devices visible in architecture views, and are these adequately managed?
• Which mechanisms and products (in different hosting environments) are being used to secure services and restrict access to them? Which services are being accessed without mediation by a security gateway and what are the security risks involved?
• In terms of service interactions, is there a significant gap between the real-life application landscape and the models maintained by enterprise architects, which are believed to reflect the “as is” situation? Is the organization entangled in a “spaghetti SOA” without knowing it?

When these and similar questions are asked, it is likely that a timely response is expected and that the answers need to be based on accurate information. Relying on a kind of inventory done before is not an option and there is no time for a yet another inventorying effort. In other words, the organization must be supported by an instrument that can provide accurate insights into interconnections of the actual application landscape.

SoaScape has been developed for that purpose. With SoaScape, the questions listed above (and similar) can be answered with ease; the necessary information about applications, interfaces, services, and interconnections is always at hand.

Why SoaScape?

The natural question arising is: why would an organization need an additional product on the top of already implemented API Gateways? Isn’t it so that mainstream API gateways offer comprehensive facilities to manage the usage of APIs?

To start with, SoaScape does not compete with API Gateways in any way, it complements these. Organizations choosing SoaScape are expected to continue using API Gateways adhering to best practices and the respective vendor’s recommendations.

The goal of SoaScape is to provide unified views over the interconnections of the entire application landscape; the views which are accurate, not bound to a vendor or a technology and which may span concerns from the operational to strategic levels. Such a functionality is not in scope of any established API Management product; it can rather be found in Enterprise Architecture Tools. However, those tools are commonly not suitable to be used for operational purposes. Moreover, the accuracy there is of lesser priority and the information about interconnections registered in those tools is commonly entered by hand (and not maintained in a structured way).

The following principles guided the design of the product:

• As much as possible, information about interconnections has to be retrieved from intermediary devices (such as API Gateways and Message Brokers). The intention is to minimize the administrative burden of keeping information up to date. The sources may include API-configurations, policy rules, client certificates, a variety of log files …
• The internal data model of SoaScape should be reflecting the modern and established architecture concepts and technology standards.
• The user interface must be intuitive, performant and highly responsive
• The product should address concerns of diverse users, stretching from strategy to operations – the information stored in SoaScape should be made accessible on different abstraction levels.
• The implementation must be simple, with almost no technical footprint in the organization

The primary target users are members of the team/department responsible for managing API’s and application-to-application connections (teams formerly known as “SOA Center of Excellence”). Other beneficiaries (with example use cases) are:

• Members of IT operations staff. SoaScape can be used to instantly determine service dependency chains – find owners of API’s, queues, topics, services, identify service policies …
• Software architects and developers. SoaScape is a Service Registry and can be used as a primary source of information about application services.
• Owners of application components and services. SoaScape would provide accurate and detailed information about interconnections of their applications.
• Enterprise architects and the CIO. A permanently up-to-date view of the “as-is” application landscape encompassing all interconnections would be at hand.

Product Features

The currently supported features include (but are not limited to):

• A structured registration of application-components, application services, API endpoints and all application-interconnections, including not only APIs (webservices), but also: queues, topics, shared files, shared databases and others.
• Visualizations of application landscapes (or selected subsets of it) with a variety of tabular and tree representations and 3D diagrams.
• Version registration for webservices (APIs) and application-components;
• Extensible property lists for application-components.
• Support for multiple (separated) runtime environments (for example: development – test – acceptance – production).
• Online (static) reports including 3D visualizations.
• Data exchange in Excel and ArchiMate exchange format.
• Automated detection and processing of API-Gateway configuration changes, including the processing of IP-whitelists (current support is limited to Layer 7 API Gateway)

Planned Features

• Automated discovery of API interconnections from log files.
• Dependency path visualizations through 3D animations.
• Automated processing of configuration changes for other types of API Gateways (other than Layer 7 API Gateway).

Availability

The product is fully operational and available for download on this site.

The use of SoaScape is and will remain free; the software is provided “as is”. The process of organizing the product support and making the software available as Open Source is ongoing.