|
|||
![]() |
|||
Wednesday, December 13. 2006EXPLAINING SOA TO THE BUSINESS AUDIENCEBeware salesmen bearing inappropriate children’s gifts at this festive time of year! Service Oriented Architecture is about creating services - period. Business people understand services. They have been doing this for years. Services usually have contracts associated with them. Useful services will ALWAYS have contracts between the provider and the consumer that establish common understanding of the offered service and terms and conditions of use. Even if the service as simple as a dry cleaning and laundry service there will be a price, a ticket, agreement on the price, type of treatment (starch, no starch, folded or on hangers etc) and an expected delivery date. There are also questions of risk and liability. Does the customer have to pay if the cleaning fails to remove the stain on the sleeve? What happens if the garment is damaged? The fundamental idea of the service is that I can separate the providing and using tasks. To make use of the service I don’t have to know how to operate the washing machines or how to iron shirts. All I need to know is how to describe the service to the provider. If the provider chooses they can subcontract the service to another provider. In fact they may have separate contracts for different dry cleaning and laundering services for different materials such as wool, silk, suede, cashmere, leather etc as well as ironing and finishing. They may have different subcontractors for week days and weekends, or even every day of the week. All these separate subcontract services are aggregated into one composite service that is presented and agreed with me the consumer. But let’s not get too carried away with over simplification and analogies, we can only carry that so far. The contract “we” are talking about is a complex specification of service capabilities. It specifies the message signature, sequences and behaviours, (tell me this and I will respond in this manner), as well as dependencies and rules (pre and post conditions) and information usage and then a host of properties that cover the operational requirements. The service specification is therefore a formal and comprehensive statement that defines the obligation of both parties. There are some very significant benefits or business values that arise from this form of service architecture: Lower integration and testing effort. - Reduced cost and increased business consistency. - Assembly of custom solutions from standard components. - Reduction in existing cost and complexity. - Choice of supply enables better fit to business needs. - Diverse sources of supply enable the service market. Business Agility – the holy grail. Much has been said about the way SOA can deliver agility and I continue to observe comments that suggest everything can change constantly in an SOA. Frankly this is dangerous nonsense. In a large enterprise change needs to be controlled both from a technical and business perspective in order to manage quality and regulatory compliance. But what SOA does give us is an enhanced ability to cleanly separate the things that do need to change from the things that don’t. In this commentary I have touched on many aspects of architecture that can deliver agility including reduced testing and integration effort, standardization and assembly into variant process designs and increased source of supply. But the bottom line is that SOA enables agility by creating an architecture that has clear, formal, contractual separation between the moving parts. This is a fundamental and profound change that reduces complexity and serves to facilitate as well as contain the impact of change. The idea of Lego blocks is actually very misleading. LegoTM blocks are homogeneous and proprietary – they all have the same interface, they come from the same supplier, they don’t interface with other building blocks and they don’t do anything that remotely looks like a service. Furthermore, LegoTM isn’t even a good example of simple reuse any more. Modern Lego kits are extremely complicated - they contain a large number of single-purpose blocks, and you have to follow a precise set of assembly instructions. Making a castle according to the specification is hard enough; making an entirely different castle with these blocks is practically impossible. The metaphor is more relevant to an old fashioned enterprise application than service architecture. If we try to communicate new ideas in such a superficial manner it should be no surprise if our business colleagues completely fail to understand us.
(Page 1 of 1, totaling 1 entries)
|
QuicksearchCategories
SLCM & Governance
Vendor News Industry Case Studies UI and Process Design for SOA SOA Refererence Architecture SOA Delivery Process Organization Patterns Adoption Roadmap Service Operation & Management Business Case Business Modeling for SOA SOA Governance Operational Infrastructure Development Infrastructure Service Portfolio Planning Technical Architecture & Deployment Planning Service Provisioning Service Implementation Legacy Modernization Service Customization & Assembly SOA Principles All categories |
||

