Services Oriented Architecture (SOA) is commonly misunderstood but if understood and used as a methodology it can be really beneficial to an organization. SOA is a design methodology based on creating collections of smaller software pieces that provides complete functionality to a larger and more complex application. What does that mean? It means that small pieces of a large application can be produced independently. The SOA method allows for these smaller pieces to be reused across multiple applications, for instance if your organization’s business practice is selling apples, multiple applications like a sales and packing/shipping application may all need to know the current apple inventory at the orchards. This inventory system can be exposed via an interface to all systems inside your apple business. Many practitioners of SOA have moved away from Application Programmable Interface (API) programming methods and have moved towards creating Web Service Interfaces for their integration purposes. This is not however a requirement, meaning that if one were to implement a SOA design in their Apple business, it doesn’t mean that you need to redesign all of your tools. SOA can also be implemented in phased approach, to reduce “Silos” of data, create a unified interface for all systems, and can assist in reducing the management footprint.
How will SOA eliminate data silos, allow for a unified interface and reduce your management footprint? Data silos are eliminated by implementing a SOA based architecture because if the systems are exposed they can be used in any other system. This allows for data to be shared easily across organizational structures as well as only needing to have data in one place, thus removing the silo stigma. SOA allows for one interface design to be shared across the enterprise easily based on the fact that all functions and software can be interfaced with programmatically, so your system design for Sales and Packing can look the same while interfacing with different pieces of software throughout the enterprise. Only having one place for each function that is exposed in your SOA design, means that you only have to maintain that function in one piece of software in your enterprise. If you have one program that provides inventory of apples to all business sections of your apple business, you support less code than if your sales system and your packing system both had their own inventory tracking system.
There are a lot of misconceptions around SOA. Here a few that we have come across while talking to people about SOA. We use web services therefore we are a SOA design. Web services are a way people have created the interfaces for their pieces of software. I am not an advocate that it is the only way to implement SOA from a technological perspective. You can have a Web Service that does nothing but show data, that doesn’t fit the SOA design really well because it doesn’t allow for interaction between multiple small systems in a greater system. SOA is a buzzword with no clear definition. Much like a lot of other technical approaches there have been multiple symposiums and also multiple large companies that have implemented SOA designs. Verizon, Comcast, Department of Treasury, and the Patent and Trademark Office just to name a few but there are many others that have successfully design their architecture using SOA principles. The “Cloud” is a requirement is the last misconception I will address. The “Cloud” isn’t a requirement, a network is. Just because you will be connecting systems over a network doesn’t mean that these systems need to be hosted in the cloud for them to work, but it is a benefit that they can be, and can be shared across domains over the Internet securely.
According to the 2ND International SOA Symposium the values of a SOA design are more business driven than technologically driven, the key tenets are business value and strategic goals outweigh technical strategy and project level benefits. The main technical goal is to share services, add flexibility, and to refine evolutionarily as opposed to attempting to put out the perfect solution the first time. It will seem like a lot of the projects we work on as IT professionals will embrace some of these values or possibly all of them. I would suggest looking at your organizations current strategic plan, and your current technical architecture and see if implementing some SOA methods and values might help your strategic plan become successful.
The post SOA What? appeared first on MetroStar Systems Blog.