Service-oriented architecture (SOA) is a concept which is regularly misunderstood and also erroneously perceived to be a silver bullet solution which will enable companies to align technology more closely with their business needs.
Closely associated with Web services, SOA is, however, different. Web services is an implementation of SOA; you can use an IDE (integrated development environment) to create Web services without understanding the technology, rationale or design processes.
It is literally a three-click process. Therein lies danger: the IT department can easily service-enable everything - but are they doing it correctly? Understanding the principles is important if business value is to be created from the software infrastructure. While the terms are sometimes used synonymously, this is erroneous; a Web services-enabled environment does not necessarily equate to a SOA.
It is important to note that there is no new technology that goes into SOA, while Web services technology is ubiquitous. What SOA offers is a way of structuring software components to get additional benefits in a standardised way. It won`t necessarily provide anything unique or additional, it is just one approach of software design which does not negate other approaches. For example, any SOA is built directly on top of object-oriented technologies.
Of course, like any enterprise technology project, there are risks associated with implementing an SOA. Chief among the risks regards the level of granularity; if the architecture is broken into too many individual services, there is the risk of having more calls (intra-software communication) than necessary. This drives up complexity and can affect performance. Why developers get this wrong is because existing integration like RMI (Remote Method Invocation) and Com, were fine grained. These tend to get wrapped in a Web service, perpetuating the granularity. Rather, developers need to work at a higher level of abstraction to avoid unnecessary complications.
Another major risk is that of setting off at the wrong starting point. What is necessary is a look at what the business is going to get from SOA and how it will measure this success; the best method is to maximise the benefit of any project while minimising unforeseen aspects of integration which can bite you.
Maintaining control over SOA projects is also critical; you could end up with hundreds of services which may be difficult to manage, especially where these are transversal (operating across the organisation). Changing how one set of users interfaces with the service could create significant problems for other users. It becomes a question, then, of IT policy and governance.
Ensure data privacy, authenticity and integrity when implementing SOA and Web services is obviously important in corporate scenarios. You need to pay more attention. The technology and standards exist for securing the SOA and Web services environment, but it does become more complicated. Too often the only security service applied is lip service - that`s not good enough. Where previously an application might have used a Com object for a specific function, with SOA it could be any one of a number of services. How this affects security is that at each point, it is necessary to verify that data still intact and secured at each end. Defence in depth requires that very link in the chain is secure to maintain application integrity.
Finally, creating or implementing SOA has as a key question the maturity of the organisation. Businesses looking to move to SOA have to go through four levels of maturity, as described by MIT Sloan. It starts with application silo architecture and ends in SOA; what`s important is that progression from these levels is linear. A company can`t skip any phases, or it is doomed to go back and learn the hard lessons of the leapfrogged phase. Moving to SOA has to happen iteratively and predictably; problem is, there are a huge number of methodologies and approaches. The company has to choose the right one for its needs since there is no one size.
Share