Apache Jackrabbit is an open source content repository for Java. It is fully compliant to JSR 170 specification,
I am an ardent fan of this utility.
If you are really looking at a small scale implementation of a Document/content Management system like say something to cater to specific regulatory compliances etc , then Jackrabbit is for you.
Jackrabbit can be used for the back-end document management system. The Jackrabbit Library services should be utilized for rendering the DM services. It does provide search and retrieval, version control and email services to name a few. Anything that is not available could be built as a simple webservice. The UI needs can be customised with any home grown system. The good part is it can well be integrated with search engines like Lucene, another Open source option.
Talk about open source exploitation !
Friday, April 20, 2007
Thursday, April 19, 2007
Vendor Land is a Wonderland !
I was at the AIIM conference in Boston last month. The Expo hall there was Amazing, what with the number of ECM vendors out there ! They were players of all sizes and each of them tried to sound more competitive in what they offer to the other. If you are new to this ocean called ECM you are bound to get lost there. At some point I wondered if number of products in the market would surpass the Content Management demand.
Honestly it looks like there are tonnes of them out there.
Vendor evaluation like i mentioned in my previous blog entry is a Science by itself. It is very important to have the right choice of product.
Often I have seen companies choose ECM vendors without performing the 'Fitness test'. The choice is mostly driven by the product shop the company already is. For eg, if the company's ERP is on Oracle apps, Database is Oracle, the obvious choice they go for ECM is suites from Oracle too. While Oracle may be offering the best of breed product in ECM, without the product evaluation based on their specific requirements the choice may really not be right.
The key to ECM success is having the right tool in place. Evaluate properly and be right the first time !
Honestly it looks like there are tonnes of them out there.
Vendor evaluation like i mentioned in my previous blog entry is a Science by itself. It is very important to have the right choice of product.
Often I have seen companies choose ECM vendors without performing the 'Fitness test'. The choice is mostly driven by the product shop the company already is. For eg, if the company's ERP is on Oracle apps, Database is Oracle, the obvious choice they go for ECM is suites from Oracle too. While Oracle may be offering the best of breed product in ECM, without the product evaluation based on their specific requirements the choice may really not be right.
The key to ECM success is having the right tool in place. Evaluate properly and be right the first time !
Health (Check) is Wealth !
Many a times in Portals and CM implementations I have realised, the first step in the Road Map really should be a good Health Check or stock taking of the existing home grown systems across enterprise if any. The reason I say Health Check is because performance issues of existing systems for the most part form the basis of the Technology shift that the customer is looking at. For example if the enterprise has its CM system implemented on Technology X and the system starts acting up, the immediate reaction to it is to blame the Technology and indulge in frantic decision making around tool shift, architecture shift etc. An RCA at the end might actually reveal that what was needed was a tweak around the current Design and efficient capacity planning, not really heavy investments in new tools.
Now, when I say Health Check it could also mean a good due diligence of all thats available currently. Some stock taking that could be done before plunging into mega implementations include:
Analysis of the problem or the business case: It is important to analyse the exact trigger that initiated the need for a new system. If the problem lies with Design of an already existing system then some patch work around components might be the solution. If the problem is around infrastructure then some re-estimation around server capacities could potentially solve the problem. At the end of the exercise the need for the new system becomes convincing. You do not have to go through the hassle of migrating to a new technology if it is not necessary. I mean, given what it involves - tool evaluation, Implementation, User adoption and training.
Inventory of Re-usable components : Another advantage of doing this sort of a due diligence prior to the kick start of a mega program is the exposure to reusable resources available within the enterprise . This could be within one department or spread across multiple ones. Having seen implementations of big systems I can't talk enough of the benefits of re-usable components and tools. Why start from scratch when something is readily available to be re-used or customised ?
View road maps of multiple departments : Often I have seen that various departments within a very large enterprise operate independent of each other especially when it comes to IT initiatives. Its surprising, but true.
Its very critical to view the IT road maps of various lines of business within an enterprise. This could well become a good ground for partnering of programs that might run into Millions of Dollars.
Define the Program Vision : The word 'Vision' may sound rhetorical in a context like the current one. There was once when I worked with this company that was looking for a Records Management Solution. Careful analysis revealed this was a short-term approach. What the vision actually was to have a full fledged document management system and records management would be plugged in as one of the modules. Good that the Vision was chartered at the right moment, avoiding dual investments, redundancy and a lot of rework.
Business and IT hand-shake : Though listed last I feel this is a very critical exercise. The key stake holders of any IT initiative comprise of the business community and the IT team. The buy-in from both parties is very important for the success of any program. I have seen cases where priority mismatches between the two have had catastrophic effects, with the business community having less faith in the IT team.
Now, when I say Health Check it could also mean a good due diligence of all thats available currently. Some stock taking that could be done before plunging into mega implementations include:
Analysis of the problem or the business case: It is important to analyse the exact trigger that initiated the need for a new system. If the problem lies with Design of an already existing system then some patch work around components might be the solution. If the problem is around infrastructure then some re-estimation around server capacities could potentially solve the problem. At the end of the exercise the need for the new system becomes convincing. You do not have to go through the hassle of migrating to a new technology if it is not necessary. I mean, given what it involves - tool evaluation, Implementation, User adoption and training.
Inventory of Re-usable components : Another advantage of doing this sort of a due diligence prior to the kick start of a mega program is the exposure to reusable resources available within the enterprise . This could be within one department or spread across multiple ones. Having seen implementations of big systems I can't talk enough of the benefits of re-usable components and tools. Why start from scratch when something is readily available to be re-used or customised ?
View road maps of multiple departments : Often I have seen that various departments within a very large enterprise operate independent of each other especially when it comes to IT initiatives. Its surprising, but true.
Its very critical to view the IT road maps of various lines of business within an enterprise. This could well become a good ground for partnering of programs that might run into Millions of Dollars.
Define the Program Vision : The word 'Vision' may sound rhetorical in a context like the current one. There was once when I worked with this company that was looking for a Records Management Solution. Careful analysis revealed this was a short-term approach. What the vision actually was to have a full fledged document management system and records management would be plugged in as one of the modules. Good that the Vision was chartered at the right moment, avoiding dual investments, redundancy and a lot of rework.
Business and IT hand-shake : Though listed last I feel this is a very critical exercise. The key stake holders of any IT initiative comprise of the business community and the IT team. The buy-in from both parties is very important for the success of any program. I have seen cases where priority mismatches between the two have had catastrophic effects, with the business community having less faith in the IT team.
A prudent exercise like the one mentioned above ascertains that the cause for a new implementation and the dollar value associated with it is justifiable.
Subscribe to:
Posts (Atom)