The Next Big Thing
Posts about next generation technologies and their effect on business.

Who should be in charge of collaboration and how should we measure them?

bridge.jpgDion Hinchcliff over at ZDnet had a thought provoking post Who should be in charge of Enterprise 2.0? It provides some interesting insight into the value and approach various organizations have to their collaboration strategy. I’ve stated before that Enterprise 2.0 is a term I have problems with, but the concept of collaboration is still important.


The post did make me ask other questions like:

These issues have been talked about for quite a while, and just like the “Who’s in charge?” question the answer always seems to be it depends. I do firmly believe though that organizations need to have objectives for their collaboration approach. Something beyond “let a thousand flowers bloom” and then assess progress periodically, after all collaboration can take many forms. If you don’t have expectations and adjust based on performance, it's more of a hobby than a business activity.


To me this means there needs to be someone steering the boat, even if it may take it a while to turn the ship.

Measurement of Agility in SOA

Jurgens Pieterse in his blog "SOA agility is turning measurement on its head" concludes that, "There is no practical measure of agility in SOA." I disagree.

The fundamental goal of agility in SOA is that the same capability is used in multiple contexts, (e.g., multiple lines of business) without change to the service interface or the implementation. The degree to which this goal is achieved can be assessed by two perspectives: (1) when a business change is considered, how many services must change to accommodate the new business requirements, and (2) for services that change, how significant are the changes. The significance might be measured in terms of the cost of implementing the changes. The overall cost estimate provides a basis for risk assessment.

So, you say, how long do I have to wait to encounter a significant business change, and when that happens, won't it be too late to get agile? Well, there are two ways to consider the potential impact of a business change: First, use a business framework like eTOM from the TM (Telemanagement) Forum, or the component designs of enterprise applications to see how your services align to these best practice functional structures. What proportion of your services align well to the components of these architectures? Second, define a hypothetical new line of business or consider full consolidation in a hypothetical merger or acquisition and analyze the impact of this hypothetical business change on the existing services. The new line of business would be best modeled as a value chain incorporating new and existing services as discussed in my book, Building the Agile Enterprise with SOA, BPM and MBM. While these best practice models may not be strictly service oriented, they represent architectures that have been effective in multiple contexts.

While this agility assessment approach does not provide a continuous measure of agility, improvements to the services can continue to be assessed against the hypothetical business change. The hypothetical business change can also help identify where additional services would improve agility or achieve additional economies of scale through consolidation.

Labels: Agility| Measurement| SOA
Showing results for 
Search instead for 
Do you mean 
Follow Us
About the Author(s)
  • Steve Simske is an HP Fellow and Director in the Printing and Content Delivery Lab in Hewlett-Packard Labs, and is the Director and Chief Technologist for the HP Labs Security Printing and Imaging program.
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.