Where Not To Use SOA
SOA or Service Oriented Architecture is an architectural concept where components of systems depict data and functionality in the form of services. These services are accessible by various other components with the help of certain standard-based technologies (Thomson 2008).
With SOA one can create new applications by mix-and-match. The first step is to choose on the application needed, next identify the present components that can aid in building up the application, and lastly mix them all together (Gralla 2003).
Although SOA seems to be increasingly popular in the present day, it is not a new concept at all. It exists since the 1980s. However, the idea didn’t take root as there was no application programming interface or standard middleware that could enable it to do so. With the development of Web services, SOA has resurfaced. The underlying architecture of Web services fit together perfectly with the SOA approach. It has even been said that SOA is the key to the future if Web services (Gralla 2003).
The value of SOAs in certain situations cannot be denied. However in circumstances when IT environment is homogenous or is not really expecting any change, then SOA is not recommended (Bloomberg 2004).
If your organization only has a single vendor delivering technologies, then SOA will not be very cost-effective. For e.g. say the main purpose of your IT infrastructure is to run a website, it is not a very widespread purpose. You may have a database, two Web servers, and an application server. An additional SOA will not add significant value to your IT investment. Generally, smaller companies utilize a small homogenous network hidden behind their firewall. For such companies and those that implement single vendor technology an SOA is not a very practical addition to their basic infrastructure (Bloomberg 2004).
Another application where Service Oriented Architecture is not recommended when there is not expected change in your IT infrastructure. This situation is says “don’t spoil something that’s already working”. You have an old legacy system sitting in the corner for year’s together, gathering dust, and there is reason to believe that things are going to change in the future. Then why mess with it? This theory applies to big and small companies and organizations. Even I can say that I have computers that are more than six years old, in perfect condition and running Windows 98. Some of you may even have one with Windows 2000 approaching its fifth anniversary.
The point is that these systems, however old, may be doing a good job at what they were doing so many years ago, as long as you don’t fiddle with them. This is not only true about the systems but also the applications functioning on those systems.
Practically speaking, if there is hardly any reason to bring changes into the business logic, data flow, process, presentation, or other aspects of the application, then changing these relics to SOA may not really be worth all the effort to do so.
In the end, new approached do add supplementing value, but they never really replace those approaches that have existed for a lifetime.
Hence, it is very important to understand when to implement these new approaches and when not to.
- Bloomberg, J. (2004). When Not To Use an SOA. Available: http://www.zapthink.com/2004/02/16/when-not-to-use-an-soa/ Last Accessed 21st February 2013.
- Gralla, P. (2003). What Is Service-Oriented Architecture? Available: http://searchsoa.techtarget.com/tip/What-is-service-oriented-architecture Last Accessed 21st February 2013.
- Thomson, D. 2008. Application of Service-Oriented Architecture to Distributed Simulation. Available: http://www.mitre.org/work/tech_papers/tech_papers_08/08_1217/08_1217.pdf Last Accessed 21st February 2013.
CTO at ITweetLive.com