SOA Tech Magazine

As cloud adoption continues to rise, the so called ' second wave ' of cloud computing becomes less of a prediction and rather a reality we have to deal with. In the past 2 years or so for example, almost in every customer engagement I've had, 'the cloud' has been at the very least a topic of discussion. In most cases it has actually been within the scope of our activities. This is not surprising of course as the term 'cloud' itself can mean ten different things to ten different people. The sad part is though, that is has been years since the first wave of cloud (started by Amazon) and there's still a fair degree of confusion in the topic. In fact, I still often refer to the  NIST definition of cloud  to explain what cloud computing and PaaS actually is and how traditional on-premises middleware installed on IaaS isn't PaaS or iPaaS. This is in fact one of the main motivators of this post. iPaaS The term Integration Platform as a Service , or ...

As SaaS adoption continue to increase in organisations of any size, it's only expected that different cloud vendors will stretch their cloud capabilities to try and increase their SaaS/PaaS/IaaS footprints in a clients landscape. This is particularly true for iPaaS related capabilities, as it seems that every cloud vendor has its own related offering and they are pushing it really hard to customers even if there really isn't a one to one fit. The challenge is though, that organisations that don't carefully elaborate a cloud integration strategy and properly think this through, will almost certainly end up implementing point solutions using whichever iPaaS capability is available for the individual project.  This not only results in vendor lock-in but also increases the complexity and cost of integration. To avoid this, the first step is to of course create a carefully thought cloud integration strategy with a clear objective in mind. This should be delivering a plat...

Very large portion of the world’s business critical systems are considered to be ‘legacy’ –and so is the code underpinning them (ie COBOL, PASCAL, C, to name a few).   Although in many cases it is the case that these systems are robust, stable and fit for the main purpose they were originally built, they aren’t flexible and scalable enough to support emerging requirements mainly derived from a more demanding ‘always on the move’ and ‘always connected’ user. These systems struggle to meet these demands mainly because of the ‘monolithic’ approach on which they were built and the complexity hidden in millions of lines of code that is only understood a very few hand-full of people that still remain active from the teams that several years ago developed these systems. In almost an equal amount there have also been thousands of failed attempts to modernise these legacy systems. The ‘eating the elephant’ in one go approach certainly didn’t work, and the traditional SOA approach a...

There is no doubt that web [Rest] APIs have become extremely popular and its usage has gone well beyond just building APIs in support of mobile apps. We can see the adoption of  resource-oriented architectures (ROA)  by probably all SaaS vendors who provide out-of-the-box APIs as the means to connect and interact with their cloud applications. Take for example the Oracle Cloud . To discover and consume publicly available Oracle SaaS APIs, all one need to do is browse the  Oracle API Catalog Cloud Service  (which is publicly accessible) and just select the  Swagger definition for any given API. But (as you probably already know) the adoption of web APIs hasn't stopped there.  With the increased popularity of Microservice Architectures  , initiatives such as  Open Legacy  ,  and node.js based frameworks like loopback and sails (to name a few), API-enabling system of records is becoming a lot easier. This is putting a lot of pres...