The Oracle Australia and New Zealand Middleware and Technology Blog.

Monday, November 17, 2008

Federating or Consolidation - A buyers guide to REAL ECM and what it means to your existing solutions

If you've recently purchased or are thinking of purchasing a REAL ECM solution from a software vendor - there is one challenge that you will face. What do you do with the information in your current systems?

Firstly, let me qualify 'REAL ECM'. There are not that many vendors in the market who offer a REAL ECM solution - that is, one that is Complete, Integrated and Open and able to be deployed to the enterprise as a whole. I can count the number on the fingers of one hand so you will gather that I'm excluding vendors who offer either a point solution (WCM alone for example) or those who profess to the complete solution but don't actually provide such an architecture.

Now to the problem - if you're going down the path of ECM you have more than likely taken the specialist path historically or have acquired an organisation that had their own solution. Either way, you're now looking at managing your unstructured information effectively and in a controlled manner and want to take advantage of the latest and greatest technology and capabilities on offer from the top-vendors. If this is you, congratulations as you've taken the first step towards successfully addressing one of the biggest challenges facing organisations today - the growth of data that lives outside of the database. Within an ECM project, and I've been involved in around 100 significant depoyments in my time as an ECM consultant, you will look at two things....

1. The usability, functionality, capabilitiy, benefits etc. etc. etc. to be realised by the organisation through the deployment of ECM and if you're following a defined methodology - will take the business requirements, functional requirements and solution design stages for each and every project you run. The output from these projects will be new abilities for the business to manage their own information freeing up valuable time and resource from the IT department. If done well, you'll also save a lot of money and streamline your business processes to the point where you'll sit back and wonder how you managed things before you started!

2. What are you going to do with all the information in your current systems? You will probably have a records-management solution that looks after the physical warehouse and all the paper stored in boxes, a document-management solution that you started to deploy but realised that the end-user change management was too hard, a web-content management solution that didn't meet the needs of the business and ended up costing you more in integration services than the software in the first place and a collaborative environment where your users can talk to each other in small groups/teams but not as an organisation as a whole. Buying a new ECM solution isn't going to solve world-huge (although I've seen it sold this way in the past) but it should help resolve the issues listed above if deployed in the right way. I've spoken at length in the past about successful projects - find the article and read it if you're still not too sure about what approach you need to follow. From a functional and capability perspective, a modern and integrated ECM solution will provide you with the ability to manage your unstructured information as easily as you manage structured data in your relational-database solutions. From a historical-data perspective, there is a challenge however.

You have legacy solutions that manage your unstructured information in a fragmented manner - lots of solutions and lots of silos of data, none of which talk to one-another. Do you migrate the information to the new ECM solution or leave it where it is and federate the information?

Migration presents it's own challenges. Whilst you may end up with a single solution long-term you will go through a lot of pain (and dollars) in the process. Migrating information to the new solution isn't particularly easy and certainly is not risk-free. You will have to replicate metadata, move the content, ensure consistency of information and guarantee compliance in the process. You will spend time and money on this approach and probably cannot guarantee success - and this is not the vendor or SI's fault, sometimes things are just too hard to accomplish. So that leave federating functionality from the new system to the old-solutions....

Federating ECM capability provides two core capabilities....

1. Finding information - enabling a secure enterprise search capability from the new solution to the old repositories means that your users have a single search-interface that can deliver results from a multitude of sources. Providing this capability within an ECM solution rather than a pure-play enterprise search-tool means that information is delivered in context AND relevance to the user through a system that understands (and has been configured) to deliver the business requirments for ECM.
2. Managing information - enabling you to set-up and manage policies that impact retention and disposition of information as well as storage-locations and applying these to information in existing legacy solutions means that you have a centalised control over your entire enterprise information-set and use common and consistent management techniques.

Effectively, with a Federation approach you leave the data where it is and stop using the existing UI's for content consumption and contribution. You switch over to the new ECM solution for content-management across its capabilities and manage/leverage your historical silos of information. Most of your legacy solutions will be database-based and while you can switch off support for the package itself - you own the data and the database management solution and don't have to switch this off.

Of course, the Federation approach won't work for all organisations - each company has its own requriements and in some-cases a migration approach of all information to the new ECM solution will be a mandatory requirement. Also, there may be some solutions that you won't want to switch off - drawing management for example - as the actual requirements are pretty specialised and the health-and-safety of employees and customers maybe affected through the migration to a system that compromises on functionality.

Paul

No comments: