Skip to Content
This is just an article I decided to write after attempting to learn what SOA is all about. I thought there would be many others who would like to know what Service oriented architecture is all about. No amount of queries on any of the search engines is going to explain what it is all about because:

1) Not many are clear about the concept

2) It is a concept

3) It is a concept which is still under development

When I started off with SOA, a friend of mine said; I have checked out 10 different sites and they have 10 different explanations as to what SOA is.

During my tenure as an auditor, I have had the opportunity of having used a fledgling SOA application which I never was a SOA in reality. The company had installed the system called it its homegrown ERP. Our IT department was all in awe of the technology. I thought then that the installation was plain crap since it took multiple and lengthy procedures to perform simple tasks. But now I understand that even though the system was plagued by teething problems and interface complexities, the underlying technology was what SOA was all about.

The company had a system where there was a web based portal which could be accessed from anywhere and yet had an secure authorisation system which prevented unauthorised access. The website integrated the legacy system accounting system which it had based Tally combined with power of databases for storage of other information. The web based interface was basically made available to users and the users would merely have to click on links which offered a wide variety of business oriented services to the user. These services were for users from departments right from sales all the way back to the purchases.

The sales page allowed its users to be updated of revenue on a daily basis, enabled zone wise, region wise and revenue generating unit wise segregation of sales. The purchases menu was linked to the inventory, goods receiving and quality control system. In effect, the system did provide everyone in the organisation with a webpage full of services to perform their tasks effectively. It was something like an EAI which had a common standardized interface. I did realise that were many comparisons which tried to put in SOA as an extended version of web services.

Some reactions to SOA from both the system as well as user’s point of view

Existing system’s reactions:
The system could react in two ways depending upon what the system is like. Considering the system is a legacy application which had been programmed on some old programming language, it would go about questioning the need for such a system. Most probably the system would not be in a position to appreciate the benefits that SOA would bring in, considering the limited artificial intelligence the legacy systems would offer and also the traditional mindset I would assume such a system would have. The existing system would have sufficed when transactions where not so dynamic, competition was not so cutthroat and management never cared what the IT guys did as long as it produced their traditional everyday reports.
Things are changing fast, transactions are dynamic and ever changing, the environment changes so drastically, competition is cutthroat and management focuses on IT more than ever to make the business produce results. Considering a real life situation, Most traditional systems would have produced a few “not so customisable” reports, and would have been limited to batch processing regular clerical transactions. Doing exactly what they were told to do and nothing more. A change in the enterprise’s requirements for something new would be so taxing on the system, since its adaptability to change would be minimal. I use the word “most traditional systems” since there are many systems which sometimes even work beyond what they are supposed to do and are in short ahead of their time. But they are limited and hard to come by. No matter what the nature of these traditional systems, they have reason to get excited;
since SOA would ideally “link” them up with other applications, both traditional and conventional.
The SOA would bring in its own technologies which would further enhance the way the whole company looks at IT “services”
Assuming that most probably SOA is implemented with web services, the traditional apps now can even go online (what could be better…)
SOA is the best thing since their last upgrade since it would invent a new way of utilising their “services”
SOA would be renew their life since it would package their existing functionalities in a new manner
All those mundane tasks would now be a part of an exciting service menu (ok, this statement doesn’t mean much, but still..)
If the system were in fact an ERP instead of a legacy application it would again look at SOA with hostility. “What does SOA have that I don’t” would be what most ERPs ask. An ERP has a reason to get excited since:
The SOA would allow it to network with the older applications, increased benefits from the older, more customized apps.
More of the ERP’s functions are now being put to use, its no longer a huge white elephant since the SOA puts them up on its menu.
data from the legacy systems flows freely into the veins of the ERP (a utopian state?? I’m not to sure about it, still….)
The ERP’s complex menus and “T-codes” are enhanced by the fresh web interfaces.
It can work peacefully in the background sure of the fact that the SOA would ensure that users get what they need
User’s reactions:
From my interactions with many users of information services, there are broadly the following categories of users.
Non technical users who do not care about the system as long as it does their mundane tasks (read technophobic) – Such persons would most probably initially resist the system, however as soon they get around to understanding a bit more of the new system, they would appreciate the fact that work has in fact become easier.
Non technical users who understand technology to the extent to which it is required – would appreciate right from day 1 as to how easy work has become, chose an option from the menu and you are ready to go. They would be delighted to see that data from their legacy systems and other systems flows freely without boundaries and SOA delivers it to their desktop.
Technical users would be in fact be updated regarding what SOA is all about and their interaction with the consultants implementing SOA would ensure that they are delighted about the change

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Jurgen Lootens
    It started with machine language. Fine for simple logic but hard work when writing more complex logic. So we created compilers. The compiler takes the code and produces the machine language. Very nice. But we found ourselves writing similar bits of code over and over again. So we added structure to programming languages: reusable modules. Then GUI’s came along and with the Internet, machines needed to call on services on other machines (client/server). Structured programming languages weren’t good enough. We needed screen elements, listeners and event handlers, asynchronous calls and stuff… So we organised logic into objects, encapsulating details to make reuse easier, allowing one object to inherit logic from another object. We even tried to completely stop writing code whenever we could and instead, dragged and dropped objects to build applications. But the applications kept growing and applications needed to talk to each other to integrate information flows. The information flows are critical to the business, when the business process changes, the applications have to be flexible to deal with the changes. We realise we need to break the applications down into flexible components that use standardised communication protocols to exchange information. In other words: SOA.

Leave a Reply