The discussion around Service-Oriented Architecture (SOA) has been ongoing for a long time, but several key aspects must be carefully considered and understood at the implementation level. As a concept, SOA has a business-first context before technology comes into play, but how it translates into technological implementation is also crucial. Here are a few points I’d like to discuss.
If SOA is purely an architectural style with a business vision and no technological constraints, I have no objections. However, if it is meant for enterprise IT, infrastructure, and software implementation of business requirements, I have a few questions:
Why is there still no unanimous decision on what constitutes an SOA service and how it should be implemented? Even if SOA is not tied to a specific implementation, it should accommodate various implementation approaches.
If SOA is implemented using web services (which some disagree with), why is there resistance to accepting this and defining how web services should be structured to create SOA-compliant services? Efforts have been made to standardize SOA architecture and service/component definitions, but how many organizations are aware of, accept, and implement these standards?
If SOA is not about web services, how does it differentiate itself? What should be packaged inside a service? Should it provide a single view of customer requirements, or should it cover complete processes, including process definitions along with the necessary components to fulfill business needs?
How do we address interoperability, transactions, and security?
The adoption of SOA will continue to be slow unless these aspects are clearly defined and accepted industry-wide. Specifications remain largely in the hands of vendors, who often make them overly complex to fit their business models.
My Suggestions
- Keep it simple.
- Avoid exaggerated claims. SOA is an architectural style, like Blackboard or Pipe & Filter—it should not be treated as a new technology but rather as a set of best practices.
- Do not confuse people by saying that web services are not SOA. While they should not define SOA, this negative perception prevents the establishment of de facto standards. Promote integration through web services—they should act as facades for business services, functionality, and processes while allowing the underlying implementation to remain flexible.
- Set internal implementation guidelines, but do not enforce them rigidly. Accept an organization’s existing IT assets and improve them gradually. While defining external interfaces to the outside world can take a top-down approach, internal improvements can follow a bottom-up approach.
Comments
Post a Comment