Lately I have found myself doing something that I have not done for a pretty long time: reading newspapers and I mean real newspapers, made of paper (*). The main reason for this is that I find reading news from a laptop is pretty inconvenient when you have kids (**) and that nothing beats reading a newspaper next to cup of coffee.

At the same time I have found myself growing dissatisfied with the RSS feeds that I use for getting news and articles online and I think that the main reason for this dissatisfaction is the specialization of the content sources behind these RSS feeds. I am subscribed to a variety of content: from articles on software architecture, to financial news, to articles on design, economic development, economics in general, etc… These content sources are targetting a domain and are producing content according to that domain’s needs. One side effect is that by consuming the content provided by these sources you are getting a certain degree of specialization in the domain covered by them (which is very beneficial if you want to acquire a certain amount of specialization in a particular domain). One other side effect is that the specialization of these content sources prevents different content from getting to you and you are becoming hostage to some predefined content.

I find that by getting articles only thru my RSS feeds I am getting isolated from other parts of the world. In part for addressing this I have started reading newspapers again, because newspapers provide that general view on the world due to their format: the content of a newspaper had to be delivered as a whole rather than to be split into multiple slices which could be delivered to the reader independently. This format pretty much meant that if you needed to address new interests for your readership you needed to add new sections to it and as a result to expose your readership to new fields. The old newspaper is a home to multiple fields (for example your typical NYT covers everything from world news, to metropolitan news, to arts, business while also providing some comentary) with a news reader that is exposed to a variety of fields and an editorial team that understands the typical news reader and can provide the appropriate content for it.

This, however, changes a lot in the new media: the newspaper in the new media is getting decomposed into finer and finer slices which are being marketed to the newsreader thru various channels. At the same time the task of choosing what to read is being shifted from the editorial team to the reader which results in the abandoning of large, uniform reader bases and the creation of specialized niches.

If I were to set some resolutions for 2009 I would take a look at the fields into which I want to get some degree of specialization, keep the appropriate RSS feeds and remove the rest. While continuing to read newspapers, of course.

Happy New Year to everyone!!!!

* I recycle pretty much all that can be recycled in a home.

** I get too absorbed when reading news or articles on a computer so that when my kids want to play I cannot let go of the laptop easily, this is the main reason for which I pretty much stopped using a computer at home. When I am reading a paper I just put it down and go to play and I pick up the paper later.

Code reuse is one software development goal consistently sought for. Its main benefits are that the code which gets reused becomes an investment on which you can build later. However, code reuse has its limits when the codebase is shared by a large number of participants, limits due to communication costs and to diverging interests.

Code reuse granularity goes against the number of the participants because implementing code reuse means deciding on what is common (and prone to be re-used) and what is specific as well as on the mechanisms used for implementing the relationships between what is common and what is specific (via sub-classing, various design patterns, etc…). This process of decision starts to blur once the number of participants increases and the corresponding communication costs start to rise. Too many people arguing about what is common to all of them will have quite a few problems figuring out what they are agreeing on.

The interests of pool of participants also are also more prone to diverge as their number increases, further reducing what is common to these participants. The end result is that once the number of participants increases both the commonalities between them shrink (as their specific interests diverge) and finding and implementing these commonalities becomes more expensive (because of the higher communication costs which occur between a larger number of participants). In these situations the code which gets reused starts to boil down to the main architecture classes within which the participants to the projects are coding their specific classes.

Keeping the number of participants low (agile techniques suggest keeping the number of participants below 7) is a way to deal with a codebase and a way to encourage code reuse efficiently.
However, sometimes you may end-up with a high number of participants. In this case code reuse should be brought down to re-using the main architecture classes in order to avoid confusion born out of mis-communication.
Another technique to deal with a large number of participants is to partition the code-base in order to minimize the number of people which are sharing code, the less people are sharing code the less the communication costs and the more things they will have in common.
Big, unpartitioned codebases come with big problems from what I have seen so far.

I am following with a great deal of interest Amazon’s offerings to the point where I think that they are the company that understands the web the most, more than any Web2.0 company including Google. Amazon brought to the world the cloud, the MTurk, fulfillment and now they are bringing public data sets. 

Really funny that an online bookstore defines the web and not the Yahoo-Microsoft-Google group. I think that Amazon is ahead of the pack because being an online retailer its competitive advantage doesn’t lie with hoarding data or its super-efficient data-centers and as a result it can make them available to the outside world without damaging its competitive advantage. One interesting difference between Amazon and the YMG pack is the rate of success of each group’s offerings: Amazon Cloud has been a tremendous success, the MTurk seems pretty busy while Google has been releasing one service without customers after another (anyone remembers Google Health?), Microsoft is paying people to use live.com and Yahoo is struggling to figure out what it needs to do next.

This retailer gets the online world and will probably define important parts of its future. The fact that its revenues are indirectly derived from the web will probably make it avoid various conflicts of interests (hoarding users’ data rather than giving users control over it being one such conflict) with which the YMG group is struggling.

A very fine blog on issues related to globalization is posting its last entries. I am sorry to see it go and I wish all the best to Daniel Altman, the host of this incredible source of information about our increasingly inter-connected world.

I have avoided reading and writing about SOA lately because SOA has attained buzzword status and the high number of articles written about it makes it pretty difficult to follow. I also see so much repetition of the same terms and concepts that pretty much every article I have read in the last 4 months feels stale once I go over the first 2 lines.

Against this background I have read 2 interesting articles on SOA: one article by Martin Fowler about using open-source techniques in order to implement collaboration between a consumer service and a supplier service and one article about abandoning the mindset which focuses on IT and rather on focusing on the relationships between various services thru contracts and policies (contracts and policies are organizational issues and not technology issues).

I found Martin Fowler’s article refreshing, even though I have to say that I disagree with it. From what I understand from the article. I think that having developers commit code to a service that you need to connect to has high interaction costs (basically the developers need to understand the partner service, need to be coordinated with the rest of developers, etc…), interaction costs which drive down the number of services with which you can partner effectively. Martin Fowler takes the issue of partnering with a service even further by having developers from the service consumer become full rights committers to the codebase of the partner service. When your developers are committers to a different service you have to wonder on what service are these developers working. The service consumers and the service providers are becoming very tightly coupled, not thru the interfaces they use for communicating (REST, WS-*, wire protocols, etc…) but thru the developers that these 2 services are sharing. I would say that Martin Fowler open-source like approach to service interactions does not scale to a larger number of services. I could go a bit into the differences between open-source projects and your typical enterprise application (I think that the most important one is that on an open source project features are chosen by boiling down competing features to the lowest common denominator chosen by the OS project participants while your typical enterprise application chooses its features in order to boost its revenues), differences which will pretty much tell why OS-like projects are very rare in the enterprise computing world but I don’t really have the time.

I have to say that when comparing the above OS approach to SOA to the typical vendor approach to  SOA you see big differences: a typical vendor assumes that services are out there in a registry and that a business analyst can create new processes and new value by drag-and-dropping various services into an IDE storing references to firm-wide services. This vision does not have much in common with the real world for two important reasons: 1) there are interactions costs associated with consuming each service, interaction costs which are not expressed in a service IDE and 2) in order to manipulate services at a firm-wide scope you need to master knowledge at the same scope. Possessing knowledge at this scope is nearly impossible, I personally have seen rather the reverse: business analysts getting so specialized that their scope becomes more and more focused. As far as I see it in order to achieve the SOA-nirvana championed by your typical IT vendor you need significant disruptions in your work-force.
And this brings me to the MWD article which echoes some thoughts that I wrote a while back when I was saying that interactions between IT services will be driven by the interations between the BUs implementing these services. SOA is not about empowering some business analyst to draw some funny diagrams on a board and re-engineer information flows at the firm level, but rather about how you create relationships and interactions, how you create incentives for adhering to rule and penalties for straying away from them, how you delegate managing an interaction to the parties involved in it, how you identify and consolidate common tasks into shared services and how you allocate tasks which are particular to a small set of parties, how you deal with who loses in these shifts, etc…

As you can see, all these concerns don’t have much to do with IT, being first and foremost management concerns. The only thing that IT can do is help these management issue get resolved, but not resolve them. IT brings some capabilities which can be used: service registries (which consolidate the view of and access to IT assets), ESBs (which allow for controlling data flows), policy standards (which allow the automation of defining and enforcing policies), etc… These capabilities should not be mistaken for their usage or their ends.
Ultimately, all the IT issues on SOA will be pushed to the back and management will take over. Ideally this field will become so specialized and its audience so narrow that we will get rid of another tiresome buzzword…

Later Edit: As you can guess this post has been written in about half a dozen different sessions, each sessions adding a few more lines to what was written before. I don’t have much time to write anymore (and I guess it shows), but I felt compelled to comment on those 2 articles because I thought they stand out from the rest of articles written on SOA.