SOA or same old architecture in other words is nothing new for people who have been using the concepts embedded as a part of this acronym in their day to day business. But for people or folks attempting a large scale transformation it still means migrating from legacy to a service oriented way of doing things. This explains why many still refer to as same old architecture. The same architecture is enabled in a service oriented way to enable others from calling services in your business function which will be useful to people integrating with your component or software. How do you do your transformation , do you attempt a big bang do it from scratch legacy modernization. What agile means are you doing in this transformation ? Do you care of delivering value in iterations or sprints . What is the risk mitigation plan in place when the services do not provide the whole value to the end user ? Are you risking everything , you do not have much of any option as you need to provide agility to business and that would be one of the business driver driving you to move towards SOA. There are multiple design patterns of enabling SOA based on your context , open source and Enterprise tools available to help in the migration. Does your team know what services to be enabled in what order of transformation to increase the perceived value to your business at the same time minimizing risk , cost and increasing visibility and measurability to your operations.
Ways of Enabling loose coupling in your Architecture :
1. Use appropriate messaging to solve integration needs.
2. Use EJB/RMI Style integration patterns ( or equivalent if coming from .NET architectures)
3. Use ESBs as the case may be , they are an overhead not always useful.
4. Use SOA Design patterns for enabling various best practices to resolve integration issues. ( many here from quick and dirty to structured / organized time and money intensive methods)
5. Reserve from scratch migration as the last option as this is time and money intensive.
It is akin to changing the wheels of a formula 1 car and still trying to win the race when others are still racing and not losing time in the overhaul when compared with the competition. This is risky in terms of providing an alternate path for existing customers who may otherwise be happy seeing their old system bottled in a new way not losing on the business focus and speed of migration. Experience here has been keep the old ways of doing things as the fallback at every stage , migrate to the new way when it solves the customer needs fully. Thereby you do not loose the customer in the process. This is where governance and plan in place will help things shape up.
Why SOA is not Enterprise Architecture ?
SOA is an architectural style and some confuse it to be the be all and end all of Enterprise Architecture. It will not be a replacement for an EA solution to a problem. EA consists of many other things that go into helping an organization reap the benefits of good architectural practices and frameworks in doing better things. SOA while some ill informed may argue that it has a governance, loose coupling , agility , reliability and also has in itself the promise of organizing the architectural artifacts and at the same time solving a business problem. But as it has been noticed an Enterprise Architect ( a seasoned one ) can choose to pick SOA as one of the many architecture styles to solve an organization problem. With REST picking momentum it seen as an alternative to SOA in many cases where there is a strong case for REST and there is a compelling need to go the REST way. REST is far more extensible and loosely coupled than SOA and has easier integration patterns compared to traditional SOA design patterns. Again based on your context either may be the best fit.
Some common myths :
You need SOA to be 100 % all encompassing. Not true only encapsulate whatever is part of your stack into a service. If it does not provide or add business value then do not publish it into a service to the external world. If you cannot think of something as a service right now , delay the decision and be lean do what is needed for the hour.
SOA you need web services to make it happen. Web Services is only a means to the end to enabling SOA. You can have SOA without having used any bit of web services.
SOA is not ESB or ESB is also not mandatory to solve your business problem. As long as people can connect to your service and orchestrate services in one form or the other it really does not matter if you use an industry standard ESB or open source solution.
SOA is enabled so we have a great architecture and all our problems of scale and loose coupling are behind us. This is also not true if you have not adhered to principles of loose coupling all long the layers including the data or resource tiers. Only if done well this would mean good SOA else you can have a bad architecture in the name of loose coupling. So you have use the best practices at some layers but underneath the hood you still have spaghetti code all sticking to each other as in the case of a monolithic application and that is not way was intended moving to SOA.
So use SOA to solve your integration problems and remember to use the best practices to do it the right way at all layers. Some may even say SOA is EA it is like saying a well oiled machinery smoothly running is the same as an entire organization or vehicle which is using that machinery. SOA is an ideal fit for helping your EA practice run smooth where it fits well. Most often this term is well en-grained in the DNA of product development in many organizations, but where people move away from legacy to attempting to do it from scratch they need to focus on the essentials meaning back to SOA design principles to get the right cadence from your architecture. Good SOA is definitely is a good EA practice.