The requirement for applications to effectively exchange data is an age-old challenge that has plagued IT. The technological graveyard is littered with integration techniques that were competitive, proprietary, or both at their time; not to say there hasn’t been progress.
Most recently, efforts have coalesced around two methods: service-oriented architecture (SOA) and application programming interfaces (APIs). Companies with legacy installations have invested millions in SOA to ensure that their internal applications cohabitate efficiently. Companies founded in the 21st century - Google, Facebook, Netflix, and others - looked toward APIs to more easily exchange data and services outside the edge of their enterprise.

Seeing the latter companies’ success, more brick-and-mortar companies - including Walgreens, Best Buy, and Ford - are deploying APIs to enable easier interaction with customers and partners, and to enable mobility. Gartner predicts that 75 percent of the Fortune 1000 will offer public Web APIs by 2014.
Indeed, some pundits want to set up a SOA versus API faceoff. On the one hand, SOA services are bulky, static or contract constrained, and must be comprehensively tested to ensure they work under a large number of conditions. On the other hand, APIs are lightweight, easy to use, and work with well-understood Internet and REST standards.
The reality is that there is never only one technology answer for all challenges; success comes from choosing the right solution to the right problem. For enterprise grade integrations, you want something that’s reliable and rugged. For external integrations, where customers and partners choose with whom they interact or where agility and performance are king, you want something easy to use and lightweight.
The question of whether to use one or the other is moot. The more prudent course involves using SOA and APIs in parallel, and managing their co-existence more effectively.   In fact, that’s what many companies are doing: using the traditional SOA stack for enterprise consumption and layering APIs on the top of SOA (or extending it) for external consumption and to meet the modern demands of the social, mobile, analytic, and cloud mega trends.  
Certainly, there are advantages to employing both SOA and APIs.
Minimise Disruption. Your legacy SOA and newly developed APIs can operate in parallel. Your SOA investment continues without disruption while you develop new APIs that run on a separate layer.
Optimise Design. The target audience of APIs is different from that of SOA services. Because the two technologies operate on different layers (internal heavy business logic vs. lightweight external access) and typically utilise different protocols (SOAP vs. REST), companies can optimise their APIs to meet the unique needs of their target users, without having to re-architect the underlying SOA services.
Improved Security. Again, because developers can isolate internal SOA interaction from external API interaction, they can employ different levels of security and protection. At the same time, though, companies must take other key issues into consideration when employing a dual SOA/API strategy.
Development. How thin or how thick should the API layer be? Should you h          ave separate development teams for APIs and services (this may add cost)? One development group is tackling business processes and the other is handling external consumption issues such as metering and authentication.
Governance. As we advocated in our earlier posting, external-facing APIs should be treated as a product. As such, there should be a product manager in charge of the overall design, ownership and management and SLAs of the APIs.  This requires a high level of collaboration between the product manager and internal technicians regarding the creation and improvement of internal functionality, because the output of the API layer is the input to the SOI layer.
Dependencies. The base functionality of the API layer is highly dependent on the underlying SOA layer. When IT updates a service, it must update any associated APIs. This is particularly difficult when there is a many-to-many mapping between the underlying SOA services and the APIs. Also, adding another layer to any infrastructure directly impacts performance.
The need to accommodate these foregoing issues should not constitute a deal-breaker for a dual SOA/API strategy. Companies have too much to gain from retaining the benefits of both structures. It’s not an either-or choice, but rather involves striving to get SOA and API to co-exist, interact, and even improve the other.
Posted by Edy S. Liongosari, Managing Director, Accenture Technology Labs and Anthony E. Harris, Senior Manager - Emerging Technology Innovation at Accenture