Software design and system development is impacted by the current cloud shift. For new software solutions, the ability to produce and/or consume APIs and related services is key. Whether you are building new applications or integrating existing ones, your teams must adapt. And the change is profound.

Monolithic architectures and the waterfall models creating them are not particularly popular these days. And this for a good reason. However, while decoupling in software architectures is fashionable buzz, much of software development still carries the mindset of monolithic dinosaurs. Project teams may do the proper and fashionable moves but continue to think inside their old boxes. If so, they fail to leverage the capabilities of their new infrastructures. And they introduce new risks.

APIs bring information hiding and separation of concerns to a new level

The principle of information hiding has dominated software engineering practices for many years. It recommends that software modules hide their implementation details from other modules to make them all less interdependent. In software architectures, you thereby achieve modularization and a separation of concerns. As a result, your software becomes easier to maintain and less vulnerable. These ideas are by no means new. In fact, they’ve been around since the 1970s.

To a certain extent, (cloud) service APIs represent yet another way to achieve this separation. But there is a difference between legacy enterprise application architectures which internally encapsulate its modules from one another, and modern applications depending on the APIs of third parties. The chief architect of the legacy enterprise application made sure the modules were combined to meet overall objectives. If desired, techniques such as dependency injection could streamline cross-cutting concerns in otherwise encapsulated modules. In our new world, by contrast, the API consumer has no means to inject or impact the inner workings APIs called.

This insight must also be considered in other software design aspects, especially when it comes to an application’s cross-cutting concerns.

Information security – a cross-cutting concern impacted by API consumption

Information security is an area that illustrates how APIs change the requirements on software design. Some examples:

• Authorization. Commonly used design patterns group user permissions into roles based on the RBAC concept (Role Based Access Control). The thinking behind RBAC goes back to the 1980s. Rooted in their traditions, software developers often continue to think of access permissions in terms of RBAC even after they have moved their software to an API consuming cloud among clouds. However, since there is no chief architect among clouds ensuring roles are globally and equally understood, the RBAC concept is outdated. Instead, the notion of roles can become a severe security hazard. To orchestrate APIs in a secure fashion, we must externalize authorization decisions from the individual API producers and consumers. They should be moved to yet another service capable of determining who gains access to what, where, why, when and how. In its decision making, the authorization service, typically a Policy Decision Point (PDP), applies the information owner’s security policies. Other services can then query the PDP using Attribute Based Access Control (ABAC) to ensure they share information in a policy compliant fashion only.
• Authentication. Before we can even think of authorizing users, we need to establish their identities. In the enterprise, this was typically done through a call to an enterprise directory service (LDAP or Active directory). Among our clouds, however, there is no single enterprise directory in charge. Instead, we need yet another type of externalized service, a trusted Identity Provider which federates identities.

New security protocols

Lastly, the way externalized security services pass identity and authorization information to consuming services needs to adapt to the needs of modern API consumption as well. Applications firing hundreds or thousands of queries to microservices per second cannot wait for each microservice to do its authentication and authorization in old ways. Instead, we need new carriers, such as JWTs (Jason Web Tokens), issued by our new trusted identity and authorization services, that we pass along with our calls.

The fact that applications, in spite of their API dependence, rarely use such externalized security services in a consistent manner, is a sign that many software developers and architects have not yet fully embraced the change that the API economy introduces. And this is the root cause in some of the security breaches we hear about in the news.

The importance of double loop learning

So, what can we learn from failures to consistently adapt to the requirements of new operational principles? Single loop learning may enable software developers to repeat popular buzzwords. To fully embrace change, they need to take yet another loop and internalize the overall objectives of the shift into their mindsets and thinking. Software developers and architects who stick to old habits may jeopardize information security.

If you are a buyer of IT consultancy services, make sure your partners in software design are double loop learners. If not, you should call Data Ductus.