Rants
Questions
Soapbox
Best Practices
Apply today for a FREE subscription to CIO Magazine!
Tue, Mar 4, 2008 15:27 EST
|
Posted by: dprgroup in Best Practices Topic: Architecture
Current Rating: |
For once there is widespread consensus: analysts say it is the next attraction; vendors say their products already support it; and some users say they’ve had it for years. Everyone seems to agree that the service-oriented architecture (SOA) is the new method of delivering software. The tricky thing is there’s no single roadmap of getting you there. For retailers mapping out a route to SOA, there’s good news though, for many of their IT organizations are likely candidates for SOA initiatives that can bring best practices in global sourcing, supplier management, product innovation and quality management.
Supply chain relationships have moved from being primarily adversarial to being collaborative partnerships. Today, retailers, their partners and suppliers need to effectively manage complexity and uncertainty – and do it better than everyone else. Take global sourcing as an example.
Retail leaders are using an increasing number of manufacturers, designers and partners in order to create differentiation through price-competitive private label products. The downside to this opportunity is that the retailer’s brand becomes ever more closely linked to the quality of goods produced by remote factories, leaving the retailer more directly involved in ensuring product quality and upholding ethical standards.
Crucial to overall performance is the ability to rapidly and effectively respond to conditions across the retailer’s ecosystem. Solutions that support an SOA strategy should also:
• capture business data efficiently and effectively from a wide range of supplier and partner systems so that process compliance and performance can be accurately gauged;
• deliver the right information to the right people, at the right time, across a variety of communities, so that the right decisions can be made;
• enable the configuration and reconfiguration of business processes across ever more complex supply chains, so that change can be implemented quickly, enabling trade, collaboration, and innovation.
Sadly, much of the integration work that links today’s processes, systems and data has been haphazard, resulting in IT environments that are islands of information, lacking true integration and powered by mish-mashes of proprietary technologies and design approaches.
SOA has been heralded as a breakthrough method of delivering software systems. Pursued correctly, Service-Oriented Architectures enable retailers to incrementally harmonize the technologies and approaches they use to integrate and change processes, and exchange data between systems, devices and people – first linking islands of integration and information, and then transforming them to become more efficient.
There’s a lot of talk about whether pursuit of SOA requires the use of particular technologies (such as an Enterprise Service Bus or ESB) and standards (such as SOAP, WSDL, UDDI and the “WS-*” set of advanced web services protocols). Some take a very strict approach, but most organizations now seeing solid business results from their SOA initiatives have focused primarily on the architecture philosophy of SOA, and less on the use of particular standards (although standards do almost always feature).
Composing software systems from sets of services offers some great benefits, if you do it well:
1. Flexibility. When a change to a system is required, its effect can be quickly identified and isolated, making it easier to manage the quality of the system and quicker to implement changes.
2. Re-use. Once designed and delivered, certain services can be shared across multiple different systems, making it more cost-effective to deliver new systems over time, and also making the quality of systems better as tried-and-tested services can be used to implement common functionality (e.g. to manage customer, supplier, partner and product information).
3. Transparency. Because services operate independently of each other, the communication links between them can be easily monitored and intercepted (security permitting).
4. Openness. Because SOA explicitly recognizes that capabilities are likely to be distributed