Monday, October 30, 2006

Dont build for reuse, reuse what you have built

All architects are very passionate about reuse. The reuse is one of the most admired and promoted principles. And often enough business sponsors of IT project seem to spurn the extra funding required to make ‘something’ reusable. That’s an irritant faced by most architects. So what is the problem? Why this seemingly smart person from business side cannot see the wisdom of building something for reuse and spend that extra cash? Is it possible that they are smarter than architects? Probably they know, by spending that extra cash they are not really going to get that reusable artifact.

May be we need to turn the argument on its head, to get the business sponsor’s perspective. Imagine an architect saying to sponsor, “Don’t give us extra cash so that we build something reusable, rather well save some cash by reusing some of the existing artifacts.” [That will be music to sponsor’s ear.] However it is a difficult statement to make.

An architect will protest, “How can we reuse something, which was not built for reuse? How do we know how well the artifact satisfies my functional requirements, let alone non-functional requirements? If I have problem in re-using it, who is going to help me out? How much additional effort I am going to spend in understanding and plumbing it with rest of my solution? Is that effort much less than the effort I would have spent in building it myself? Do I save on maintenance or am I doing ‘clone and change’ reuse?

If you look at it, most of this applies to something which was built for reuse too. How does one build something for reuse in a potentially unknown future scenario? With unknown functional as well as non-functional requirements? What organization (and of what size) one needs to support this reuse? Difficult questions! So being a pragmatic, I am inclined to give up the notion that something worthwhile can be built for as-is reuse in future, and tend to agree with those (smart!) business sponsors. Wait, before you declare me a traitor to architect community, I would like to state that some reuse is still possible.

What I believe is a reuse at conceptual level is still possible, and useful. So if we separate the concepts from implementations (a la MDA, CIM v/s PIM v/s PSM), we can reuse the concepts already built. And choose a more appropriate way, to connect with an available implementation, for the current scenario. What are these concepts? They can be anything conceptual, a business process, a conceptual data model, a set of business rules. They are closer to business requirements than IT design or implementation. Most probably you will use fragments of these conceptual elements than complete conceptual element. Does this need a full blown MDA tool set? No, not in my opinion. One needs to separate concepts from implementations using any notation that one is familiar with and have a repository of such concepts. So any new solution you are going to build, first step would be search in this concepts repository. You find something useful, (re)use it. The effort and organization needed for creating and maintaining such a repository is not huge. And of course you need to adopt a slightly different solution development practices to institutionalize this. [Well for a small consideration, we can help you there ;-) ]

So, don’t build for reuse, rather reuse what you have built!

No comments:

Monday, October 30, 2006

Dont build for reuse, reuse what you have built

All architects are very passionate about reuse. The reuse is one of the most admired and promoted principles. And often enough business sponsors of IT project seem to spurn the extra funding required to make ‘something’ reusable. That’s an irritant faced by most architects. So what is the problem? Why this seemingly smart person from business side cannot see the wisdom of building something for reuse and spend that extra cash? Is it possible that they are smarter than architects? Probably they know, by spending that extra cash they are not really going to get that reusable artifact.

May be we need to turn the argument on its head, to get the business sponsor’s perspective. Imagine an architect saying to sponsor, “Don’t give us extra cash so that we build something reusable, rather well save some cash by reusing some of the existing artifacts.” [That will be music to sponsor’s ear.] However it is a difficult statement to make.

An architect will protest, “How can we reuse something, which was not built for reuse? How do we know how well the artifact satisfies my functional requirements, let alone non-functional requirements? If I have problem in re-using it, who is going to help me out? How much additional effort I am going to spend in understanding and plumbing it with rest of my solution? Is that effort much less than the effort I would have spent in building it myself? Do I save on maintenance or am I doing ‘clone and change’ reuse?

If you look at it, most of this applies to something which was built for reuse too. How does one build something for reuse in a potentially unknown future scenario? With unknown functional as well as non-functional requirements? What organization (and of what size) one needs to support this reuse? Difficult questions! So being a pragmatic, I am inclined to give up the notion that something worthwhile can be built for as-is reuse in future, and tend to agree with those (smart!) business sponsors. Wait, before you declare me a traitor to architect community, I would like to state that some reuse is still possible.

What I believe is a reuse at conceptual level is still possible, and useful. So if we separate the concepts from implementations (a la MDA, CIM v/s PIM v/s PSM), we can reuse the concepts already built. And choose a more appropriate way, to connect with an available implementation, for the current scenario. What are these concepts? They can be anything conceptual, a business process, a conceptual data model, a set of business rules. They are closer to business requirements than IT design or implementation. Most probably you will use fragments of these conceptual elements than complete conceptual element. Does this need a full blown MDA tool set? No, not in my opinion. One needs to separate concepts from implementations using any notation that one is familiar with and have a repository of such concepts. So any new solution you are going to build, first step would be search in this concepts repository. You find something useful, (re)use it. The effort and organization needed for creating and maintaining such a repository is not huge. And of course you need to adopt a slightly different solution development practices to institutionalize this. [Well for a small consideration, we can help you there ;-) ]

So, don’t build for reuse, rather reuse what you have built!

No comments: