Create collaborative and dynamic method content using Web 2.0

developerWorks, SOA and Web services zone has just published the first in a series of papers that looks at addressing some of the ideas around context to content to enable asset consumability that I have been talking about on this blog, This paper titled: Create collaborative and dynamic method content using Web 2.0, talks about how to leverage Web 2.0 technologies to extend software development process content, which is typically published static as HTML. This article describes how you can develop the ability to collaboratively edit method content and have access to the latest dynamic content within a method context.

For this paper, and indeed many other papers, we have been fortune enough to work with developerWorks own, Patrick Flanders, and Ashleigh Brothers who do such a professional job in terms of reviewing, editing and laying out the content.

Pattern (reusable) assets classification

Reusable software assets represent significant IP in terms of lessons learned from previous engagements and can to address both functional and non-functional requirement (e.g. a performance non-functional requirement could be addressed using the requester side caching pattern asset). However, because assets are not currently cataloged against meaningful criteria, such as functional and or non-functional requirement, they are often not leveraged or reused effectively by architects to help make more consistent architectural decisions.

The importance of Architecture in an SOA can not be overstated. Yet when it comes to making architectural decisions in our software labs or on engagements there is often no consistency, tractability or accountability in terms of the decisions made. These architectural decisions are driven by non-functional requirements (e.g. performance, transactionality, tractability, scalability, etc).

Assets such as software patterns assets are often represented by many assets such as a pattern specification and/or pattern implementations and these assets are often hard to locate because of this lack of consistent and meaningful cataloging. Also the knowledge and use of a asset, such as an industry model asset is often local to a particular practitioner or architect. This leads us to a situation both in software development labs and more importantly on field engagement where is no consistency way of consuming assets and leveraging lessons learned to achieving architectural consistency traceability and accountability.

Below is a meta model that shows how reusable assets can be used to create a solution and goes into more detail and classification around a particular type of reusable asset: the software pattern reusable asset.

The many buckets problem

As I mentioned in my previous post one of the problems that we run into with mapping context to content is the multi bucket problem. Consider the following. At home I organize all my clothes into buckets.

Each bucket has a different item of clothing in it e.g. one bucket contains all my shoes; another bucket contains all my pants; yet another bucket has all my jackets.

How let's imagine for a moment that these are very sophisticated buckets. These buckets have the ability to classify all of the items contained within as well as matching items together. For example my shoe bucket has the ability to classify all of my shoes by color and size as well as matching all of my left shoes with their corresponding right shoes. To top it off these buckets have a shinny panel on the front that gives me detailed information about any item in the bucket. So with my bucket of shoes I can see from the front panel all the information that i need about a certain shoe, such as when I bought it, how often I have worn it etc.

This is all fine and dandy, but I run into a problem when for example I am invited out to a work related cocktail party. Since this is my first cocktail party I am unsure about what to wear and would like to be able to say to all my clothes buckets, please give me an ensemble to make me look good for this cocktail party. My clothes buckets I am sure will look back blackly at me, with the shinny digital displays, beeping nervously as I start to frantically root through one bucket after another to try and put together some vestige of an outfit that will make me presentable at the cocktail party.

This simple story serves to illustrate the problems inherent in any repository based information management system. However, there are a couple of lessons to be learned from this simple analogy.

1. No one bucket can be responsible for management relationships between the items in its bucket and the items in another bucket as the would quickly be unmanageable for all but the smallest number of bucket items
2. I could put all my clothes into one bucket and call it a clothes bucket, however by treating all of clothes as just generic clothes items I lose a lot of flexibility I has in the multi bucket scenario.