This is the first post of a series based on a talk I gave at the Fall CIO Summit in Baltimore on September 21st.

Find the second part of this POST here.


We currently live in a connected world : Internet Of Things, Native Mobile Applications, Off-the-Shelf Cloud Platforms, Legacy Systems, etc. Getting the right DATA from point A to point B at the right time has increasingly become a challenge. When is time to rethink our technology ecosystem? How to leverage the power of cloud platforms working in a seamless integration with our legacy applications? What is Service Oriented Architecture and how that applies to my company?

The purpose of this post is to give a 30.000 feet view on this topic to encourage debate and further research.


We live in a connected world: Internet Of Things, Native Mobile Applications, Off-the-Shelf Cloud Platforms, Legacy Systems, etc. Getting the right DATA from point A to point B at the right time has increasingly become a challenge. Even more challenging, there is no limit on how fast we expect data to travel, well I guess the limit is “Real Time”.

When I weight myself in my Fitbit Aria every morning, I want those data point to be ready to be analyzed in my iOS app 5 seconds later. In a less frivolous example, when a customer buys a product, we want to be alerted real-time, what is more, we want our warehouse, distribution center and accounting to get the data that is relevant to each of them REAL TIME.


John started his own company …

On day 1 he noticed he needed to keep track of his customers and that old notepad is not going to be enough, so after some research he founds himself owning few licenses for Microsoft Dynamics.

On day 2 he realizes he will have to pay taxes (you know, death and taxes), he needs a Billing System, and there is John owning a brand new instance of Quickbooks. But, his billing data does not make sense without his customer data… And there it goes the first integration.

On day 3 his pal Mary builds a custom Inventory System for him and also a custom integration with the Ordering System he just bought.

Days go by and John keeps growing his company, as well as his Technology footprint, he also has a cloud Sales System and many more.

Data only makes sense in the context of other data and I don’t think I need to reiterate on the REAL TIME dilema… do you see where I am going?


John Incorporated kept growing and after two years he acquired a second company …


At this point John’s IT department has to maintain multiple systems, not unified systems of records and a scenario where we could apply Metcalfe’s Law to quantify the value of the point-to-point custom integrations.

First, how do we enabled those systems to talk with each other and how we plan for that? Also how we do that in a way that makes sense, and the output of the project is something that can be re used?

Second, how do avoid the Metcalfe / spaghetti linking / ball of mud problem?




SOA has become a well-known and somewhat divisive acronym. If one asks two people to define SOA one is likely to receive two very different, possibly conflicting, answers. Some describe SOA as an IT infrastructure for business enablement while others look to SOA for increasing the efficiency of IT. In many ways SOA is a bit like John Godfrey Saxe’s poem about the blind men and the elephant. Six blind men from Indostan encounter an elephant – each of the men then describes the elephant a bit differently because they are influenced by their individual experiences:

  • The man touching the trunk believes it to be a snake
  • The man touching the tusk believes it to be a spear
  • The man touching the ear believes it to be a fan
  • The man touching the elephant’s side believes it to be a wall
  • The man touching the tail believes it to be a rope
  • The man touching the legs believes they are trees.

The blind men then engage in a series of debates about what they believe are facing them:

“…And so these men of Indostan

Disputed loud and long,

Each in his own opinion

Exceeding stiff and strong,

Though each was partly in the right,

And all were in the wrong!”

In many ways Mr. Saxe’s poem has become a prophecy for SOA. Industry analysts, pundits, bloggers and reporters engage each other in an ongoing, never-ending debate about what is or isn’t SOA. Like Mr. Saxe’s blind men, people have correctly identified many of the capabilities of SOA but largely fail to communicate the concept as a whole. The challenge of defining SOA has become so important that various vendor consortia and standards organizations have launched initiatives to try and answer the question “What is SOA?”

For the sake of this blog we will use Google’s software definition for SOA :

“A serviceoriented architecture (SOA) is an architectural pattern in computer software design in which application components provide services to other components via a communications protocol, typically over a network.”

The architectural concepts associated with SOA are not new – many have evolved from ideas originally introduced by CORBA, DCOM, DCE and others. Unlike these previous initiatives, the key promise of SOA is to enable agile business processes via open, standards-based interoperability.

SOA is an architectural approach to creating systems built from autonomous services. With SOA, integration becomes forethought rather than afterthought – the end solution is likely to be composed of services developed in different programming languages, hosted on disparate platforms with a variety of security models and business processes. I want to emphasize on the fact that SOA is an architectural approach and not an implementation, confusing SOA with an implementation style without proper planning can lead to disastrous results.



As in any other technology trend, SOA is full of Buzz words (and acronyms) so let’s cover few of them.

API – Application Programming Interface

Anybody that has done software development should be familiar with APIs. The concept has been around since the 50s . Old school windows developers – like me- have experienced APIs in the form of DLLs.

APIs are basically software building blocks, however these blocks are not anymore restricted to tightly coupled components of our applications. Cloud/Web APIs are made available by other companies for your use (sometimes for free, sometimes not): Mapping APIs, Payment APIs, CRM APIs, etc. With several benefits, like realtime data updates, realtime results and the fact that you don’t have to worry about hosting massive amounts of data. In other scenarios -where the software is still hosted in house- APIs allow you to leverage data on those systems.

Thing of Uber, their platform has been built using third party systems: mapping, payments, CRM, etc.

Companies (and their Engineering teams) can now focus on building software that serves their core business while leveraging third party specialized products through API integrations.


A Webservice is defined as any piece of software that makes itself available over the network, using open protocols. Microservices on the other hand is a software architecture style in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs (Ordering Microservices, User Microservices, Inventory Microservices, etc). This is not a new concept, the pattern has been around for a while.


Simple Object Access Protocol vs Representation Estate Transfer. As with most of technology comparisons of this style, and despite which some architects will tell you, there is no winner; and the right answer is “it all depends!”.

REST is based on Resources and in few HTTP based actions over them (POST, PUT, PATCH, DELETE, GET). SOAP is based on Service actions (UpdateStatus, RecalculateAccount, etc).

REST is “lighter” and requires less overhead, responses/data can be cached hence it is faster. It works great with Javascript frameworks and that is one of the reasons why is trending up.

SOAP on the other hand, requires more initialization overhead, however it provides enhanced security mechanisms (WS-Security), ACID transactions insurance, delivery acknowledgement and many others.

As a summary, I would use REST for most of my application, unless I have to build a high security application, like a banking application.


Another endless debate. XML is highly structured, can be validated and transformed on the fly and offers 12 defined types, but is also highly redundant.

JSON on the other hand is lean (and mean), offers fewer types and it can be interpreted out of the box by Javascript frameworks.


Service Oriented Architecture

Microservices – Martin Fowler