For the advocates of SOA, the evolution of SAP into a service economy is important for several different reasons.
Firstly, SAP applications and users represent a large block within the business IT ecosystem. Other service designers will have to pay attention to the geometry (architecture) of SAP services, since this will affect service consumption patterns in the broader ecosystems. If SAP has produced (is producing) a good geometry, with loose coupling in the right places, this will benefit SAP itself, its customers and the broader ecosystem; if there are architectural flaws, this will disrupt the service landscape.
Secondly, the internal processes and practices adopted by SAP are relevant to many large enterprises. The migration to SOA involves managing the articulation and evolution of services, managing complexity by decomposing functionality and clustering services, introducing best practice in service governance. Given that SAP’s migration to SOA affects so many people, the stakes are high - but SAP is not the only large enterprise with high stakes. The industry should be in a position to learn broader lessons from how SAP is tackling this.
Thirdly, the adoption of SAP involves adoption of business practices, not just software. Thus there is a business geometry as well as a software geometry, and the articulation and evolution of services must address several levels simultaneously.
This is why SAP’s Netweaver product is an interesting development – not just a me-too platform. SAP is coming into the SOA world from a different perspective, and should therefore have an important contribution to make. At present, at least until more hard project experience emerges, I’m giving Netweaver a guarded welcome.