• Subcribe to Our RSS Feed

Service Oriented Architecture (SOA) – Episode 2 (Myths and Facts)

Oct 25, 2014 by     No Comments    Posted under: Business-to-IT Alignment, IT Architecture

SOA Myths and Facts We started in previous episode with investigating the roots and origins of SOA concept. In this episode, we will clarify some of the wrong beliefs and myths about SOA. The worst thing is to have a blurred image about an architecture. We will start with a simple definition of SOA and will proceed to clarify various concepts around it.


Simple Definition of SOA: SOA is a loosely-coupled architecture designed to meet the business needs of the organization.

The key promise of SOA is to enable agile business processes via open, standards-based interoperability. While these standards are important we must remember that standards are not architecture and architectures are not implementations. At the end of the day it is the implementation of a well-designed architecture that will generate business benefits, not the architecture itself.

SOA Myths and Facts

SOA is a technologySOA is a design philosophy independent of any vendor, product, technology or industry trend. No vendor will ever offer a “complete” SOA “stack” because SOA needs vary from one organization to another. Purchasing your SOA infrastructure from a single vendor defeats the purpose of investing in SOA.
SOAs require Web ServicesSOAs may be realized via Web services but Web services are not necessarily required to implement SOA
SOA is new and revolutionaryEDI, CORBA and DCOM were conceptual examples of SO
SOA ensures the alignment of IT and businessSOA is not a methodology
A SOA Reference Architecture reduces implementation riskSOAs are like snowflakes – no two are the same. A SOA Reference Architecture may not necessarily provide the best solution for your organization
SOA requires a complete technology and business processes overhaulSOA should be incremental and built upon your current investments
We need to build a SOASOA is a means, not an end
SOA is ESBESB is a useful tool when you're building a SOA but it's not mandatory for SOA.
SOA and BPM are competitive technologiesSOA and BPM are in fact complementary. BPM are often used to orchestrate SOA services. In some cases, the opposite is done — SOA services invoke BPM flows.
SOA is expensive and over-engineeredThere's nothing about SOA principles that should add cost to projects. In fact, SOA projects tend to be cheaper and faster. SOA generally increases the reusability of services.
SOA will be replaced soon by cloud computingSOA is an approach to architecture. Cloud computing is a way of deploying aspects of architecture, including SOA. They are related, but very different.




If you enjoyed this post, please consider leaving a comment or subscribing to the RSS feed to have future articles delivered to your feed reader.

Got anything to say? Go ahead and leave a comment!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>