City Planning
Actually the job as an information architect in IT is a bit of a funny one, since in information architecture it is very rare you actually design something for construction (I assume technical architects and solutions architects are closer to the construction of stuff). Information architecture is closer to a strategy & planning job. I like making the analogy to the job of a city planner; information architecture is all about knowing where we have the main traffic jams in information flows, where we are building new processing plants and creating the understanding how all these elements relate to each other. To stretch the analogy, information architecture is closest to planning urban renewal!
When we talk urban renewal, then I immediately can tell you that many of the existing methods in architecture (e.g TOGAF, Archimede, ...) are to much geared towards greenfield sites or systems that do not cover large & complex enterprises. They assume we create from scratch complete designs covering all aspects of the architecture stack, whilst in most cases we just adding bits and pieces on top of strata of diverse IT systems, that are like layers of a historic town. Information architecture is therefore more like working in an archaeological excavation, than doing planning from a blank sheet of paper. Unfortunately this is the reality in most businesses today. We have usually quite a few decades of legacy and the job of the information architect is to carefully plan structures that do not damage what we have, whilst providing improved capabilities for the future. More on my City Planning challenge in my later posts ...
Labels: City Planning, information architecture, methodology
New series!
Has it been two years? I look at the blog and realise that time flies when having fun. In the mean time the world moves on and I pick up new learnings that I hopefully can share.
I have moved to a new job, high up in the ivory tower of a large global enterprise, looking at information architecture, enterprise wide .... and a lot is happening!
Labels: new job
Technology again
MRD management turns quickly into an overengineered cottage industry. You cannot imagine the number of components that make up a good MRD service - here to name a few: a data store supporting flexible data models that can keep track of every change in every attribute (and maintain their history), message-based integration to any other data store subscribing the with MRD content, workflow for the MRD maintenance, roll-back capability if something goes wrong in the process, attribute level security, ... etc etc etc. All great, but do we really need it, or is this becoming architecture for architecture sake? Personally I think this is MRD in the hands of technology-people and not MRD for the sake of better integration & quality. So my advice would be to start from the ground up and see what the requirements are one by one. Addressing them is usually possible in the existing systems. When the requirements for the services grow, then migrating to a generic MRD service may become an opportunity, but not as a start!
Labels: master reference data
Types of Master reference data
I have been pulled into some detailed discussions on Master reference data management and through this it occurred to me that there are different types of data that need a different treatment. Here are a few examples:
- The first type I would like to call 'external standard lists' - this is the reference data for which we already have (international) standards (like ISO). Examples are Countries, Post codes, Units of Measure, Language codes. Characteristics: Standard is defined, source is outside the company, no debate necessary. Approach: Just identify the data type and agree to use the standard from now on. Even better is to make it centrally available as a service.
- The second type is similar - but I would call them the 'internal standard lists' - things inside the company for which you like to have an agreed enumerated list - i.e. a fixed domain. Think about standard lists for security levels, status codes, ... Characteristics are: Standard is usually a lot harder to define due to debate from different stakeholders, while this debate is not really adding a lot of value. Approach: Identify the data type, propose a standard after analysis. Challenge the parties to make a case if they don't think they can comply to this standard. Make the standard lists available as a service.
- Third is a type you should skip and this is the set of items that people think as common attributes, but which are actually not manageable. Think about document types (everybody has a different opinion), keywords, names of project teams (too many!), etc. It is hard to define this category, but it is usually about lists that change constantly, that do not have a clear source or owner and where there are no clear definitions (or where it is just over the top to manage it as reference data!). I see a folksonomy as a good alternative for this category.
- Finally the fourth is the most important category - and that is for objects / things / people shared across the company the 'master reference objects' - this data you probably already maintain in one place or another and the trick here is to get agreement where you have the master etc. (stuff I covered before). Note that these objects can be organised in hierarchies - which in themselves can be seen as reference data (but lets leave that for now!)
Labels: folksonomy, master reference data
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
