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

CBDI Knowledgebase
CBDI News / News Item
   
 
 
Tuesday 6th January 2004
COMMENTARY - A SERVICE ORIENTED MANIFESTO
Regular readers of the CBDI Commentary and Journal will be aware of the huge body of knowledge that we have already built up in the area of the SOP. During 2004 we aim to extend and reengineer this resource into a more accessible and prescriptive set of process guidance. As ever we always welcome your feedback, and we look forward to working with our members in what promises to be an exciting year.

A Happy New Year to all our members.

TOP REPORTS FROM 2003

SERVICES ORIENTED ARCHITECTURE -
PART 1 - THE FOUNDATION
CBDi Report

MODELING FOR SOA – WORKED EXAMPLE
CBDi Report

UNDERSTANDING SOA
CBDi Report

GET THE CBDI WEB SERVICES ROADMAP
Available for download from CBDi Report



TOP NEWSWIRE COMMENTARIES FROM 2003
(Note to access these archive items you will need your Bronze,
Silver or Gold login)

6th February WS-SECURITY TEST RESULTS
CBDi Report

27th March - WEB SERVICES USAGE SURVEY - RESULTS
CBDi Report

10th July The INTERNET IS DYING
CBDi Report

24th July SOA REALITY
CBDi Report

7th August WSDM THE MISSING LINK
CBDi Report

14th August MEASURING BUSINESS VALUE
CBDi Report

30th October MICROSOFT UNVEILS LONGHORN
CBDi Report

6th November MODEL BASED DEVELOPMENT ROCKS
CBDi Report
ABSTRACT: Time and time again we hear the same message - that technology issues are generally relatively easy to resolve. In contrast resolving people and process matters generally takes more than mere rocket science.     
    
Our high tech industry is driven by continual change and the introduction of new product/technical capabilities. Even in this somewhat depressed period we are all managing constant change and what's more than a little surprising is that the industry generally manages the technology change process so badly. Of course the primary driver of innovation is the fiercely competitive technology product development. But while the technical product capabilities are driven forward at full tilt, the processes and practices look suspiciously like an afterthought.     
    
Now you may accuse me of being a cynic, but it would be easy to conclude this is a deliberate vendor strategy; now that most of the major forces in the industry are product AND services companies, it is very much in their interests to "sell" the essential guidance and advice on how to successfully deploy the technology.     
    
Whilst there is undoubtedly some element of truth in this, I accept that at the very least the major vendors have to discover for themselves what best practice is, before they themselves can productize it. Further the vendors are increasingly in the position that their core strategy is to service outsourcing of complete business processes, and they can perhaps with some justification argue they don't need to productize the guidance, merely to ensure that their workforces are properly equipped.     
    
But this is not adequate. We will always advise that a critical part of awarding BPO and or outsourcing contracts should be an assessment of the process in use. The nature of the service oriented world is about collaboration, and there needs to be at least some level of common process which will allow synchronization of the collaborating partners' processes. Finally the development of best practices is a genuinely more difficult problem than developing the raw technology; the process is the intersection of practice and technology and by definition needs to adapt to an infinite number of situations. The process is the application of the raw technology.     
    
THE PROCESS AS A NETWORK OF SERVICES    
Strangely enough our business colleagues understand the word process, as a body of knowledge and guidance for the task at hand, better than IT people. Mention the word process to the proverbial IT person in the street and the likely response will include RUP, or similar "development" processes. Yet the IT solution world has changed massively over the past few years and most IT solution activity is about integration and application evolution. But there is no real consensus on appropriate processes or methods that span the lifecycle.     
    
But the process concept itself is set to change, as a direct consequence of service oriented thinking and systems. Today most processes resemble a production line - they are linear, chronological and cumulative. Yet service based technologies allow us to view ANY process as a network of services which, being a set of services can be completely non linear, asynchronous and collaborative.     
    
A good example that we noted last year is the process reengineering work undertaken by EDS and productized in their E-vis tool - which provided a process management network which has evidently driven big productivity improvements in GM's vehicle engineering process. The real time visualization and collaboration tools enabled design collaboration, electronic purchasing, new product introduction project management and engineering change management, integrating internal systems and component suppliers using Web Services.     
    
NO NEED TO COMPLETELY REINVENT THE WHEEL    
In the IT solution delivery world there is an urgent need to develop process guidance for the service life cycle. Today's de facto processes as mentioned are predicated on fundamentally different architectures.     
    
Strangely enough there is a body of guidance already available for certain aspects of the Service Oriented Process (SOP). Some organizations have properly embraced the Component Based Development (CBD) process which is firmly founded on the principles of interface based development and strict separation of provider and consumer. But these are in the minority. Sadly many organizations have been deluded into thinking that they are adopting CBD, when in reality they have been using a more casual approach, which permits or encourages sloppy definition of components and interfaces, and fails to sharply differentiate between object and component architectures.     
    
Of course the SOP needs to cover a much wider scope and life cycle than Component Based Development. It needs to support the integration of services with business, and the creation and constant evolution of the network of services. It will include key characteristics including:    
- Heavily business focused    
- Managing collections of services    
- Inherently loosely coupled    
- Separating provider and consumer    
- Integrating diverse parties, architectures & technologies    
- An automated network    
- Higher level of abstraction    
- Delivering evolutionary and constantly changing functionality
 
Read Full Article / Link to referenced materials
   

  © Everware-CBDI Inc 1999-2010