Social Networks
There is a lot of exitement in the industry about Social networks (already for some time). We all know by now the MySpaces & Facebooks of this world and I wonder if this is really worth the billion dollar fuzz (apart from for the advertisers).
In general we see that these networks are 'walled gardens' - a bit like AOL in its old days and although there are some announcements of opening up, I do not see the phenomena as much of a paradigm shift as the last two major changes: the surge of Google and Wikipedia. In my case Linkedin is the only place where I have registered myself, which is great for finding (former) professional contacts, but I hardly can see how they make serious money on this, or how this will drive a general revolution. A new development which is gaining more press is Ning from the former Netscape guru Andriessen (now valued at $ 600 mln). This is a place where you can create your own MySpace, but to be honest it is hardly more than a more configurable version of Yahoo Groups ...
But can we learn from this? Does it mean anything for Enterprise 2.0? You would think from my starting remarks that I would not think highly in terms of impact, but to be honest there is probably more to the Social Networking thing for Enterprises than for the general WWW ...
First of all I think that the concept of a 'walled garden' works well inside a company, since that's a natural fit. Second, there is a lot to gain from better team working. People have a tendency to take care of their own stuff ... when given the freedom. Third - I do not think we need to make a technology shift! We can use we have - it is mainly a culture change.
Probably the best place to start is exploiting Microsoft's Sharepoint, which can be set up to serve team sites, personal sites, blogs etc. Just like an in-company MySpace ... The main change is a shift in mindset from 'control' to Web 2.0 thinking. There is probably no need to regulate this, since the power of search will allow information to be found. If something is highly connected, and used widely it will score higher in the ranking - no need for taxonomies here!
What are the benefits? Probably we will see more content moving online. We may see better team work, since it will be easier to set up collaboration environments for various teams (our web masters today make life too difficult to do this) and finally doing it well will give you an opportunity to get rid of shared drives!
Bottom line - social networking will support moving away from hoarding and show the road to sharing.
Labels: Web2.0
Master reference data and Folksonomy
Building up master reference data in terms of key objects in the company is difficult, but doable. Building up a reference data list in terms of 'information types' (e.g. document types, or other taxonomy) is even more difficult. From experience I can say it is usually a disaster (too much detail, too complex ...). Therefore the concept of a managed
Folksonomy is very compelling alternative. It is a Darwinian answer to data management (let the fittest document types survive). The approach could be as follows:
- Data managers can start with a first cut list of information types and other attributes available for users to pick and choose - the data managers can even do a bit of a mapping exercise to some of the documents, so at least some information is linked to the information types
- Then users are invited to use the document types for their own publication processes (probably with an accellerated speed if a document type is a mandatory attribute). Allow users to choose from a picklist or to create their own if they don't know what to choose
- Create statistics and remove the taxonomy entries with a low number of links - invite the users to reclassify if they have used the removed items
Through this gradually the list of types will grow and they will become fit for purpose.
Labels: folksonomy, master reference data
Search vs Structure
Search is the religion on the Internet today, with Google as its high-priest. And the story has become so convincing that IT executives in companies start to believe that we can do the same inside the walls of a company. Earlier I already wrote about a Google pilot (the
Power of Search) and then I already noted that Google has some advantages, but definitely not all the answers. So before we take the plunge towards relying everything on Search we need to step back a little and think. We could make the same mistake as we did when we moved to desktop computing (which was a recipe for anarchy in terms of information management).
Funny enough the other hype - around master reference data management - is at the other extreme end of the scale. This is where we try to set up the taxonomies of the company. So it could be that the answer is in the middle: We should do 'Search' - it helps if all information is indexed and easily available ... and we should see what we can do to define some key master reference data objects, because this will provide a mechanism to provide more context to the information we try to index. Information related to master reference data will rank higher and the reference data itself will provide navigation in the mountains of results available through search. So the seamingly extreme ends of the scale actually provide building blocks for the retrieval architecture of tomorrow.
Labels: Google, master reference data, search, taxonomy
Governance
A lot about Data Management or Architecture is related to governance, or in other words - related to the way we decide about our priorities. So the key role in DM and Architecture is to shift the focus to data and providing structure. This is quite a major challenge, since historically the focus in IT has been on
- Functionality before data
- Project delivery before reuse
- Hardware before intangibles
And therefore the shift in governance will be hard since all our managers have grown in a culture where functionality, project delivery and infrastructure are king.
So how to make them change their minds? Here are a few ideas:
- Organise an audit with an unsatisfactory result (think Sox, or what ever is relevant for your organisation) - you can even invent your own set of rules and call this a Management System
- Show the cost of acquiring data vs the cost of applications - include all cost (man hours for handling, QC, ... etc.). The information asset has no bottom line - but through the transparency of its acquisition and handling cost it becomes clear how much value has sunk into data
- Change your architecture pictures with more focus on data & reusable components and less on the core functionality of applications
- Show clearly what you're planning to do with the money. Usually the application people have a simple cost picture: license cost + support = total sum and a simple result (now we have it installed with 5000 users ...), while data cost are harder to add up and cannot be linked to specific installations / usage. Tangible actions are easier to sell (then you can always slot in the less tangible later, once you have credibility)
- Understand what is seen as critical
- Start small and make it scalable (e.g. clean up one type of data for one department, don't plan to improve everything). if you can show in the pilot that 20% of the data was wrong and 30% of the data not retrievable, then the business will wake up (especially if it is seen as critical data)
Just a few ideas - but they are proven to help!
Labels: architecture, governance, Information Management
Master reference data - revisited
I get the feeling data master reference data is another hype in the making. In my previous post I already about two titans gearing up for the big fight in this space, but apart from that I see now also all EAI vendors and of course all consultancies coming up with a Master data story ... If it gets like this in the IT industry, then get yourself ready for a bubble (and a burst after all the promises are not met after huge investments ...).
So let's get back to the original problem. Do we want to manage master reference data? In principle I would say yes. But then the next question pops up: Do we really want to have the data managed separate from its usage? And here I start to feel doubts! I think it is good to understand what is master reference data, where it resides in the different systems and boring stuff like ownership etc. But to have it completely separate ... I don't know if this is a good idea. If we would have an Information Asset Manager in the company with a clear bottom line responsibility for the data asset's health. Then yes, I get more positive, but even then I think we could do the job with just a set of good procedures and some proper interfacing.
So consultants:
let's focus on what really counts, and don't try to sell us another expensive solution!Labels: master reference data
Master reference data management tools
A few weeks ago I have seen demo's of the new Master data management (MDM) solutions of SAP and Microsoft. And it is interesting to make a quick comparison. Let's start with a quick description:
SAP has been trying for some time now to come up with a good offering. It has been a struggle ... Their current product is based on a catalogue type of tool, where there is a central master table (e.g. Product or Customer) - designed for fast performance, which you can relate to a number of hierarchies of classes. The tools has its origin in vertical markets (e.g. eProcurement and CRM). The tool allows data cleansing and some basic workflow for maintenance (although it does not allow iterations), but it does not really do any integration (e.g back into R/3, surprisingly this is not available out of the box). In general I see the tool as a difficult and not so useful tool, but having said this - the new release is promising a lot more, with support for more complex data models as the biggest improvement.
Microsoft has no history of data management, so therefore I treat any development in this space with interest. All I have seen is a pre-release (based on the product Stratature, which they bought some time ago) - but it seems like they've got a good strategy in mind. 1) the tool is made compatible with the other products (Sharepoint, Biztalk etc) and 2) they treat it as a piece of infrastructure, i.e. they see a set of foundation elements (generic for each type of MDM service) and on top of that they allow vertical solutions.
Could it be that Microsoft is going to outperform the big old ERP vendor when Microsoft MDM finally gets released? Personally I think this will be an interesting game, since Microsoft owns the desktop and can become the key to content management (Microsoft MDM may start to power the taxonomies of Sharepoint). While SAP owns the back-end, but if does not get its own act together on putting SAP MDM center stage with R3, then it will fail in the long run.
Labels: master reference data
