A couple years ago, many asked whether SOA would kill ERP. I do not know the answer to this question but I certainly know that ERP vendors do not want to sit and wait when such thing happen. They have started to migrate into SOA (maybe hoping to kill it first).
Well, we have to be accurate with 'migrate into SOA' because this means only that ERP products started offering Web Services as communication means. In reality, this is killing SOA indeed. Why? Because communication via Web Services has nothing to do with service-oriented architecture. The ERP products did not change their internal components making them operating on the principles of service orientation; instead they attached new interfaces that had word 'service' in their names. Such futuristic migration into SOA is similar to calling 'flying fish' a 'bird'.
Nonetheless, there is one rational in this story. Many products now offer their features via Web Services. This is quite positive movement because Web Services accumulate significant number of standards and we can say that access to many products is much more standardised now than before. We certainly need a term, which can indicate the 'webservice-ation'. What Web Services bring to the products? It is a simpler standard-based ability to integrate with other systems and products. So, let us call it IOA - Integration-Oriented Architecture. Such architecture concerns about standardised integration means, which may be not necessary Web Services but REST and other technologies.
All right, doing Web Services, we are doing IOA!
(And, please, leave SOA for services)
Reference: IOA to be pronounced as [ī-ˈə-ä], similar to Iowa
Michael, I agree there is possibility that most ERP product vendors did not change their internal components they just attached new web services interface,I'm sure we can call them Integration Oriented Architecture (IOA). I think there are two issues here 1) As SOA is the new buzz word a ERP vendor can't say that their product is not based on SOA. 2) It takes lot of time to change their internal development methodology and components based on the principles of service orientation. One thing I learned long time back in software industry there are two mountains to climb in this industry one product development and other one is marketing/sales. We have to climb both at the same time.Develop soon so we can market and sell faster. Apply a patch now and fix later. This is happening every where, so my question just like other development managers. How to start SOA for my organization,I have web services what next.?
Prakash,
Thank you for the comment. Answering your question “How to start SOA for my
organization,I have web services what next?” I would not tell you ‘It is quick and easy. Start small and grow’ because it is not true. If SOA may be quick it definitely not easy, and we have to define ‘small’.
SOA is not easy because it requires very serious knowledge and preliminary analysis. The analysis is similar to what is called ‘feasibility study’ in Agile Methodology; SOA is architectural methodology, it is not a technology. So, first questions are:
Why do you need SOA or systems operating on service-oriented principles (see http://www.ebizq.net/blogs/service_oriented/2009/02/principles_of_service_orientation_reviewed.php)? What for? Is you business ready to OPERATE in services rather than in processes (see http://www.e-technologymanagement.com/tm/index.php?option=com_content&view=article&id=159:breaking-stereotype-collaboration-vs-process&catid=36:soa&Itemid=81 )? Do you know business objectives that require utilisation of services?
The knowledge of such business needs and ‘rules of IT engagement’ in the service-oriented operations should be written in the IT/SOA Governing policies to be available to architects, manager and developers as well as to the business architects and managers.
To answer those question we need to define where the power of SOA is. My opinion (based on OASIS SOA RM and RA-draft standards) is this: in the fast changing market, business has to be very efficient to survive and grow; efficiency is based on flexibility in adopting changes; capability of services to quickly migrate from one collaboration into another is the solution for adoption of business changes. This is why SOA is a key solution for enterprise business and, respectively, IT.
How you create re-composition of service collaborations – via reuse or whatever – does not matter for the solution. The fundamental requirement here is that your service has to implement concrete business task, function, feature or process. If you have a few business services like mentioned above, you can compose them into business applications or products. This leads us to the development approach.
SOA services can start small but end-to-end. This means, the service has to include all: related business operations, user interface, business logic and business data meta-model. All of these – for just one business feature, then, fro another one, and so on. Since SOA is the architectural model or style, it must go throughout the full technical stack; you cannot make a service in business logic having monolithic UI: if you have components already working for this UI, you will not find strong reasons why you need re-develop them into services (because the reason sits above this layer, the reason is in the business flexibility but non-modified UI will kill flexibility of the components-converted-into-services).
As a manager, you have to be in the position where you can recruit business into SO approach and influence the entire technology stack. ITIL v.3 can help you in political battles. As of ERP, they are too big to be decomposed into separate services and then re-composed back into multiple service collaborations. I do not think it is doable. However, if you build ERP functions from the green-field, you have a chance to make them services. Finally, Web Service is not a service, not at all. It is an interface to the service. Service is the one the consumer is interested in: service provides business functionality and results (Real World Effect) while interface provides connection/communication to the service capabilities.
I hope that my long answer has demonstrated that there are a lot of things above Web Services that are needed to start SOA and win.