Wednesday, February 27, 2008

Unity & integration

Last week I went to a presentation by Jan Hoogervorst, an ex-VP for IT strategy at a major airline. It was the first time I've seen some real practical usage of enterprise architecture. Jan's definition was quite narrow - to him architecture is mostly presciptive (not descriptive - as in pretty pictures) and aims at unity & integration in the portfolio, with the focus on risk areas. How straight forward! Personally I like the pictures as well (a picture says more than a thousand words ...), but his message is clear. Just show the rules of the game and then you're in business as an architect!

Labels: ,

Thursday, February 21, 2008

Workflow

Supporting clever workflows is one of these holy grails in IT. And it seems that we are not able to crack this very easily. We have of course at one side of the spectrum the very retrictive transaction processing (I do the payment, my boss approves ...), and here we have made quite some progress (nothing difficult here). But the other side of the spectrum is where it gets more interesting.

More complex is trying to get a handle on the more diffuse ways of working, medical protocols, research, ... In the 1980's we have seen attempts at expert systems, but they never really became mainstream. And also now, 20 years later, all I have seen to date is very basic ... Of course we do very clever stuff with demonstrator robots from Sony (and others) that recognize patterns and know how to react on this (this is a step forward), but in the office domain I am still looking for a breakthrough.

Why is this? Probably because a lot of what we humans do is not easily replicated. Workflows like the analysis of a data set, or writing a report on a difficult subject, or developing an idea are still very fuzzy and hard to define. The only thing we have today for this part is the more control oriented workflow, where we check that we have taken the right steps (i.e. protocols, like used by doctors), or that we have documented what we have defined is mandatory (i.e. tracking of mandatory deliverables related to decision gates). The first one is not main stream yet (so I still expect more developments in this space) and the second one is so basic, that I hardly can call this workflow. So we have to settle for the simpler higher level type of workflow - and still wait for the breakthrough!

Labels:

Monday, February 18, 2008

Collaboration tools

As information architects we have a challenge when dealing with the large number of tools emerging the last decade in the space of knowledge management. The worst area of KM is related to the many types of collaboration tools - where for the sake of simplicity I would like to exclude the ones related to direct communication (like e-mail and instant messaging).

I think in short there are roughly three types of collaboration tools; 1) common interest networks (like the old news groups, and newer hypes like MySpace, etc.), 2) collaborative bookmarking & tagging (think del.cio.us) and 3) collaborative authoring (think Sharepoint in the Office area, but this also includes wiki's and blogs).

So when your KM architecture requires collaboration, then define what types of collaboration are required and how they relate. My view is that especially the collaborative authoring world that emerged holds the biggest potential for improving the way we manage knowledge. It moves the focus from approvals to content creation and that's what it should be all about. So when rethinking your collaboration space - think wiki's first.

Labels: , ,

Sunday, February 17, 2008

Knowledge management

As soon as you mention the word 'Knowledge management' people will start to become uncomfortable. Maybe they will grin (and stop taking you seriously), maybe they will try to move to a different subject, or even worse, maybe they will have an opionion about document management.

Just as I wrote on 'architecture' I think the world of KM is suffering from a high degree of immaturity and because of this we see a vast number of methods on offer.

What we need is a reference model, a model which describes all aspects of KM. Just try and read the entry in Wikipedia and you will see how much people have struggled with some definitions (it received more than 500 edits last year, so no wonder ...). Shouldn't we just make it more simple? My view is that we have three types of things in KM - that are all very different: 1) Different types of Collaborative Content creation (formal / informal), 2) Systems that help you through workflows (protocols, expert systems) and 3) stores with Knowledge in the form of reference information (like e.g. Wikipedia).

Around these three families you will find lots of tools & flavours. And also a lot of hype (like all web2.0 stuff). So if you need elements of KM in your architecture, you will definitely get lost! But if you just focus on the three elements (collaboration, workflow protocols and knowledge reference) then maybe you have a chance ...

Labels: ,

Saturday, February 16, 2008

Information Asset Manager

Nowadays de CIO of a company is usually an IT person taking care of buying desktops, the contract for the network, some application development, etc. In short - the CIO is mainly in charge of the T of technology, and therefore in most IT policy the T is more important than the I of information.

My vision is that in the future this will be moving to become an Information Asset Manager. Gradually we are seeing the commoditisation of desktop support, networks, and even lots of applications (to me SAP R3 is also a commodity ...). Hopefully this will give us more room to focus on what really counts - out assets, our information assets.

Probably this will require a new generation of managers, since the current generation at the top (and below) has all been grown and rewarded in a technology culture. Therefore we should be hiring a different type of people today to become the managers of tomorrow. Else we will nog see a culture change (and therefore no step change in the way we manage information!)

Labels: ,

Saturday, February 09, 2008

Application Services

Probably the big paradigm shift currently happening in the industry is the move to 'Services' hosted by 3rd parties. Who wrote some years ago already that the 'network is the computer'? (well, it was one of Microsofts rivals - SUN). This vision is becoming a reality now. Why have Word and Outlook installed, if their online sisters are more reliable, cheaper, ...

Right now Google apps is growing to become a serious competitor of Microsoft, and even Amazon is entering this market with offering storage services ... Soon we have SAP moving to a service model (they are already working on this for some years) and soon after this others will follow.

This trend will give new opportunities and challenges to the industry. The opportunity is that we get the option to focus more on what really matters for the company (because services like storage, word processing, accounting are becoming commidities, just like electric power ...). The other challenge is that we need to rethink the way we manage our networks. At the end of the day the only asset that stays is 'our' information (the data and documents) that need to be managed, protected, etc. Opening up to market services changes this model.

I see it mostly as an opportunity, since it will put information management firm at the center of what we have to manage!

Labels: , ,

Thursday, February 07, 2008

Immature methodologies [2]

As I wrote earlier - the architecture methodologies are not mature. So what do we need? I think we need a simple protocol (with examples) for making inventories in the different stages of architecture development. For example:

  • stage 1, list main drivers & objects, then create an architecture vision based on how architecture can contribute to achieving the main objectives
  • stage 2, create a context diagram and list the core functions and related business services, assesss for each function or interface if it is an issue / improvement area and then prioritise, based on the key objectives from stage 1
  • stage 3, list key functions & key data types, create a mapping matrix between the two, and check where the identified key issues of stage 2 should be address (e.g. through rationalisation of the architecture) ...
  • etc.

My view is that a good architecture method should provide a simple cookbook - step by step - with some minimum standards for a few diagrams and decisions trees. Most methods I have seen try to do this, but go overboard with too much detail, too many different types of diagrams and a clear spill over into the system design space.

Labels: ,