CBDI Forum
CBDI Service Oriented Architecture Practice Portal
Independent Guidance for Service Architecture and Engineering

CBDI Knowledgebase
CBDI News / News Item
   
 
 
Monday 7th February 2005
AN OPEN LETTER TO MICROSOFT ON INTEROPERABILITY
CBDI February 2005

Text of Bill Gates letter is at http://www.microsoft.com/interop
Last week Bill Gates wrote to Microsoft customers on the topic of interoperability. This is the CBDI response which has been sent directly to Bill Gates and Microsoft's PR agents. We will be pleased to publish any response.   
  
Dear Bill,   
  
BUILDING SOFTWARE THAT IS INTEROPERABLE BY DESIGN
  
  
CBDI recognizes and fully supports Microsoft’s efforts in delivering interoperability to enterprise systems customers and its leadership together with IBM and others in driving the development of WS-* based standards. This focus on practical integration and interoperability is a primary reason why Microsoft is making good progress in the enterprise systems market.   
  
The creation of open interoperability standards is turning out to be a long term project, and while there is good progress we would have to say that much remains to be done. But even though there are areas where consensus has not yet been reached, or where protocols are taking longer to reach maturity than anyone expected, we make the fundamental assessment that this industry project is going to succeed in delivering the technology neutral interoperability layer that is urgently needed by enterprise customers.   
  
WS-* ADDRESSES OUTER LAYER OF PROBLEM  
Making disparate applications and environments work together is a major step forward for the industry and an essential architectural layer, and all organizations need to implement this, but it is only addressing what might be regarded as the outer layers of the problem. Interoperability by design must go beyond loose coupling of the message interchange stack, because the level of loose coupling is always going to be strongly influenced by the behaviours and dependencies of the underlying applications. While WS-* protocols permit a significant step towards creating what might be termed normalized services which can have a significant level of concurrent shared use as well as reuse in different contexts over time, the behaviours of the services will be constrained by the underlying implementations.  
  
Over the past year we have discerned a growing awareness and concern amongst IT and business managers with the huge complexity of enterprise systems environments, and the associated costs and inflexibility this causes business operations. Most large organizations are already overburdened by middleware and other integration technologies and products that establish bridges between very complex application portfolios. As they implement service oriented architectures using the new interoperability protocols they are creating looser transport and message description couplings between applications but they are usually adding yet more layers of complexity. For example stateless behaviours in the XML layer require new logic and additional intermediate data storage in order to transform older synchronous application architectures. So called composite application architectures are essentially acting as facades, hiding and working around the core systems complexity.   
  
We provide one simple and very recent example where a major German electronics manufacturer wants to change the logistics operation and is faced with a high risk, eighteen month project that is a major inhibitor to business achievement. Yet this is a software system where a Web service API infrastructure does exist and yet the systems change process is taking much longer than is deemed acceptable. This type of situation should be of concern to enterprises and enterprise application developers. Microsoft, along with SAP, PeopleSoft, Oracle and their customers all face the same situation that their core products and applications reflect legacy architectures which are essentially monolithic and hard to change.   
  
BUSINESS AND TECHNICAL RELEVANCE OF SERVICES  
Recently we have observed many early adopting SOA customers reaching the conclusion that componentization of the applications layer is an essential next step once the technology neutral interoperability layer has been established. Medium grained components implementing clusters of tightly related services establish a multi-layered service architecture enabling lower risk, rapid response to change. This approach also forms an optimal scope for specification, delivery, deployment and resource management, which substantially reduce dependencies, enabling ISVs and enterprises to evolve their application architecture very rapidly, maintaining the integrity of architectural layers, rather than applying sticky tape on the outside.   
  
The new WS protocols also provide the foundation for a genuinely business driven service oriented architecture. Business people understand services extremely well, and the concept of the service provides us with a precise construct that allows complete convergence between business and technology perspectives right across the life cycle. We suggest that within the next 24 months we will have the technology foundation that is adequate to implement the business viewpoint directly and we should be encouraging business involvement in the systems and service delivery process so that business managers understand and take some large measure of responsibility for decisions on the opportunities and limitations of particular architectural and design choices.   
  
Today many enterprises look for superficial interoperability solutions because the risks of restructuring core systems are seen to be very high. Yet service oriented architectures enable progressive restructuring and renewal by establishing a formal interface layer around disparate implementations. We observe that as experience of SOA techniques grows, the cost/benefit equation for renewal alters substantially, particularly if TCO including lost opportunity costs resulting from the lack of agility are considered.   
  
OPPORTUNTIY FOR MICROSOFT  
We are aware of many initiatives within Microsoft where these issues are being worked, and we believe Microsoft is genuinely taking a leading position in delivery of service oriented architectures, raising the level of abstraction of specification and enabling service life cycle based systems. All these actions are significant enablers in reducing complexity and enabling interoperability by design not just at the superficial level, but at all levels of the architecture.   
  
We believe that simplification initiatives will inevitably become prioritized by senior business managers because relatively superficial interoperability improvement programs will not deliver the expected or required level of business adaptability, nor substantially reduce the costs of maintaining the typical levels of systems complexity. In contrast simplification programs should become synonymous with greater business agility, because the well structured architecture will permit extremely rapid change on many levels and dimensions.   
  
SUMMARY  
In our opinion interoperability by design is a worthwhile long term goal, but focusing on enabling collaborations between disparate systems is merely the first step of a much longer and far more important journey. Addressing the issues of interoperability and complexity in a thorough manner will deliver genuine business agility and we recommend that for Microsoft this is an issue that deserves a similar level of attention that was given to the Internet and Security. We urge you to take this broader view of interoperability by design and to provide leadership and education in this critically important area. The attainment of broad industry standards of a technical interoperability layer is of course very important, but it is only the first step, and we encourage you personally and the Microsoft corporation to articulate this vision to your staff, partners and customers.
 
Read Full Article / Link to referenced materials
   

  © Everware-CBDI Inc 1999-2010