You know the old debate between PL-SQL developers and Java developers: “Your Java app will never run as fast as my PL-SQL programs”, “you will never be able to pass a message to an external system and update a DB row at the same time”.

Well, the 2 camps are both right, PL-SQL is very good at performance, while Java is very good at modeling an application. We should use each platform’s strengths. So what would follow from this approach? Well, I think it is pretty obvious: create small PL-SQL procedures focused very well on their target and orchestrate them in Java. Avoid creating big PL-SQL procedures because one side effect of this approach would be creating high complexity in a language and a platform that doesn`t deal with complexity so well. Calling these small PL-SQL procedures amd assembling them into larger blocks from Java code is basically orchestrating them from a platform that handles complexity pretty well.

Do this and you will have a Happy New Year!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

The biggest cost associated with knowledge is learning: in order for one person to absorb the necessary knowledge so that it operates efficiently in a particular environment it is necessary for it to learn that knowledge. It is important to acknowledge this cost because the cost of operating in that environment without the necessary knowledge is typically greater: a person/team operating with insufficient knowledge has large management costs. Taken to extreme insufficient knowledge can lead to micro-management.

Disseminating knowledge is a process usually tied to the domain to which that knowledge is pertinent, to the organization dispersing the knowledge and the people that need to receive that knowledge. In this process you have to rely both on people as well as on systems in order to make it more efficient. Ideally, you would not swamp the persons with requests about knowledge, but rather put them in a position where they can guide people needing the knowledge to the appropriate knowledge resources.
Documentation is the primary vector of disseminating knowledge about a project*, it is the first point of contact between a person and that project and a point of contact to which someone will refer continously during the interaction with that project. It is important that we acknowledge this double role of documentation (initial point of contact and then continous point of contact) and that we structure it to accommodate both roles: a high-level view for initial contact and a lower-level view for displaying the internals of a project.

The knowledge about a domain “encapsulated” in one person depreciates slowly for a small period of time and then rapidly as more time passes with that person outside of the domain. For example, a person that is absent from a domain for a small period of time, during which the domain has changed, will be able to absorb the domain changes quickly, if it has been absent for a big period of time it may have problems getting back in shape. However, previous domain knowledge will help.

Storage and retrieval of knowledge is usually expensive. The more “fuzzy” the domain of that knowledge the more expensive it gets to retrieve good knowledge about it. In “fuzzy” domains you usually rely on people to get to good information. In “fuzzy” domains you will also need people in order to resolve conflicts in the interpretation of knowledge. It is important to identify these persons and set-up a communication channel with them.
The need for people in processing knowledge is probably one reason for the informal networks that get established in large organizations: sometimes it pays to know who knows something, sometimes it is the most efficient way to deal with knowledge. Getting to a person that knows something that you need to know is a process of discovery which will ideally be optimized.

Blogs can be used for delegating knowledge management to a person that is motivated to provide that knowledge continously. Bloggers are pretty attached to the subjects they blog about and are likely to follow these subjects and report on them efficiently (at least good bloggers should report efficiently). These reports constitute knowledge about the blogger’s subjects which are pretty precious. Another nice thing about blogs is that you can initiate conversations with their authors and get pointers from them, blogs act both as systems for disseminating knowledge and as people disseminating knowledge at the same time.
In an organization blogs could be used for finding persons that have knowledge about something and for contacting this person about that knowledge. We should be able to differentiate between blogs and to assign blogs to various knowledge resources.
I think there is a lot more to knowledge management in blogs than I can express right now, I will leave this for later.

The book Economics of Knowledge by Dominique Foray is a pretty good book on this subject.

* I will use the term project as the object to which knowledge applies.

Customer service has emerged as one way to fund an open source package which grows so much that you cannot support it by relying only on code committed by random committers: you release the APIs under a particular license and you pay for the expenses by selling support subscriptions.
This obviously applies to one small part of the open source movement because there are open source projects which get funded in a different manner: RedHat sells customized versions of Linux, IBM provides corporate backing for various open source projects, pooling of corporate resources for maintaining other open source projects, etc…

As far as I know tech support is used for backing various open source projects such as a variety of Linux flavors, JBoss, Spring Framework, etc… Tech support relies heavily on the lack of knowledge of operating that open source package: you have some problems configuring JBoss’s transaction manager and the cheapest way to deal with it is to open a ticket with JBoss rather than try to jump in to the free code. Tech support is actually outsourcing the management of the knowledge required to operate a particular product and as such it feeds on the lack of knowledge about that product. If your product is big and hairy (think about a stack) but widely used you will make a lot of money from tech support. Tech support revenues grow as the complexity of operating that product grows because tech support is tied to the knowledge required to operate that product.

Tech support runs counter to light-weight frameworks, from their definitions they are light and easy to handle. Which makes you wonder about how would a framework championing light-weight development would be able to sell tech-support subscriptions. You will probably sell tech support to Fortune 500 companies which require support for most of the software they use (requirement which is probably a by-product of internal rules more than anything else) but anything else will probably be a tough sell. I understand a 20-person company buying tech support from JBoss for managing their application cluster better but I don’t understand why would the same company buy tech support for a lightweight container. By definition the usage of that container would be so straight-forward as not to make you need support, you should be able to solve a problem either looking it up on that framework’s forums or thru the documentation.

That’s why I am following Spring’s model with a lot of interest: the very goal they are trying to achieve (an easy to work with and non-intrusive framework) runs against the rationale of supporting that framework thru subscriptions to customer service. The steps that they are taking, such as releasing value added packages probably shows that supporting a light-weight framework is not very efficient and that you have to resort to a different model for funding it.
I would say that this new strategy is promising because these value-added packages will increase the knowledge required for efficient operation and implicitly the need for tech support.
Kudos to Spring Source for breaking away from an old model.

Later Edit: Tech support also relies on the complexity required for interacting with a particular product, be it an operating system, an application server, etc… The more complex the product, the bigger the need for tech support. Spring Source`s products so far were not complex to operate, on the contrary, their objective was to allow for transparent, non-intrusive development and ease of operation is part of this objective. With Spring Source move into value added packages they also move into more complex products (if you look at what Spring Integration is trying to achieve you will see a lot of very complex interactions between various products in the Spring Source stack). The more complex these products, the bigger the need for tech support. It will be interesting to watch how this will unwind.

Probably the most interesting thing that I read in quite a while is the paper “The Nature of the Firm” ** by Robert Coase which can be viewed here. Ronald Coase answers a pretty interesting question: why in some cases it makes sense to gather resources together to carry out an economic activity while in other cases it makes sense to delegate that altogether to an outside party.
The answer lays in the extra costs that lay in carrying out a transaction or, as they are known, in transaction costs. Let’s say that you want to have your own house. You have 2 choices: one is to sub-contract parts of building the house and orchestrate the activities of the companies that you have sub-contracted: the one that pours the foundation, the one that puts up the walls, the people that paint your house, etc… or you can delegate the operation to the external entity, the home builder. The costs of each choice are (at first sight) the following:
1) carrying out the orchestration on your own: paying for the company that pours the foundation, the one putting up the walls, the one putting up the roof, etc…
2) delegating this to the home builder and paying for all of the above (the home builder will have to pay the sub-contractors just like you do) + the profit of the home builder who will be doing the orchestration for you.
At first sight it appears that you should be doing all the stuff yourself and come off cheaper than by delegating this to the home builder. But apart from the costs of the subcontractors you also incur the costs of interacting with them: you need to inspect the work of each one because you don`t know how good that sub-contractor is, you need to look around for good subcontractors, you waste a lot of time negotiating with them, etc… No suprise that most people prefer to go with a builder***.

What basically The nature of the Firm says is that if the costs of carrying out the activity on your own are less than the costs of delegating this to a dedicated party you should carry out this activity on your own rather than delegate it. You can see Coase’s theorem at work in the current outsourcing/offshoring trend: the transaction costs for outsourcing some operations are so low to the fact that a corporation can delegate efficiently various tasks to outside partners.

So how would this apply to software development? I would say that transaction costs demarcate pretty well what needs to be grouped together and carried out by one entity (which assumes a specialization of some sort) and what needs to be delegated to a different party. Well, this is what is needed for architecting a project: you need to determine how to group various classes, packages, systems together so that they minimize the interactions between them. The interactions between systems (or classes or packages) can be thought of as transactions: one class calls the other to do some work just like a home-builder calls the carpenter to install the hard-wood floor. By looking at the transaction costs between various components of an application you could determine what transactions (method calls) should be consolidated into component that handles them and what transactions should be allowed to exist on their own.

I would say that one big cost associated with a method call (or call to a package/outside system) is extensive orchestration between various classes (a method that calls 15 other methods from 7 different classes). If you have a pattern of method calls repeating over your code-base you should probably try to take a step back and consolidate these calls into a component that will serve the purpose of that particular orchestration. This way you will create a specialized component to which you delegate this orchestration, rather than replicating it multiple times. Efficient specialization of the components will incur lower transaction costs because it will push down on the number of interactions between components. For this you need domain knowledge. While designing a system you should look for specialization and for ways to achieve this specialization and once this specialization achieved you should look for ways to interact with these specialized components efficiently. If this is done properly you will end up with a system in which the cost of interaction between various components is low.

Another big cost for interacting with a different system is knowledge about the other system and class. The more knowledge you need to have about an external entity the more costly it is for you to interact with that system: you will need to be kept up-to-date with changes in this knowledge, there is a ramp-up cost, you can handle only this much knowledge, etc… It is a good thing to minimize the knowledge required for interacting with an external entity, this way a component can interact more efficiently with other components.
One corollary would be that you need to externalize as little as possible from any component and try to keep most of its sub-components private. One side effect of having too much of a component available is that you run the danger of a component coupling to it unnecessarily.

One cost for interacting with an external system is API coupling: the fact that you need classes exported by that external system**** in order to connect to it. If your system shares classes with an external system you will need a way to synchronize the shared classes with the external system. This is done usually either by having the external system having different versions for its points of interaction or by having a mechanism that publishes classes used for interaction. Either alternative is pretty costly, so you may try to keep away from sharing classes with an external system (though sometimes it may be impossible).
Transaction costs can be applied in project management as well: you should look out complex interactions between teams and try to assign them to a resource best dedicated to handle them (this resource could be a team-member, a well-defined process, etc…). However, in this case you should avoid assigning this interaction to a real person because you will run into scarcity constraints (i.e. you will run out of people) very fast if you keep delegating to real people. This is why these interactions are probably best addressed to a process.

I think that developing a software project while keeping an eye on the transaction costs is a good approach.

Later Edit. Transaction costs are very useful in determining the interaction between large components (systems, services, applications) and they are probably best used for managing this interaction. When you design the interaction of various systems the interaction costs (which are transaction costs) should be kept to a minimum for that interaction to occur without many problems.

* In this post transaction will be used for its economic meaning: i.e. it will stand for an exchange between 2 parties.

** If I am not mistaken Ronald Coase received the Nobel prize in economics for his work on transaction costs and this paper.

*** Please note that there are people that actually build their own houses on their own. The vast majority of them are in the construction business or have connections in the construction business so their transaction costs are a lot lower that for the ordinary person.
On a different note, the orchestration needed for building a home (calling the people that put up the jeep-rock after the 2/4`s have been erected, calling the painter for painting the walls after the walls have been put up, etc…) is a very simple business process without any intrisic value and prone to copying. No wonder that the builder itself makes a pretty small margin while the lion`s share of the profits go to the entity which owns the land…

**** You are generally sharing classes with an external system if you interact with it via RMI or EJB. Interacting with an external system via WS-* or REST is a lighter coupling.