Notes on stuff

Tagged Posts: EnterpriseArchitecture

The Architecture of Personal Knowledge Management – 1

Back in July Harold Jarche posted a useful deconstruction of the processes involved in web-based personal knowledge management (PKM). Building on this, and in order to make a lot of implicit stuff in my head explicit, I’ve started developing the model into a full mapping of processes to tools.

I’ve chosen to use Archimate as a modelling language, and as I develop the model offline I will be posting views of it to pages liked from this wiki page.

Harold’s model looks like this:

As I began to unpick Harold’s seven processes I realised that although they are primarily focused on “self”, one key aspect to understand them is to identify the different roles that “self” (and “others”) play. This aspect of the model so far is shown in the Introductory View :

Alongside the work of developing models for each of the processes, I began to develop a view of the key information artefacts manipulated by the PKM processes.

I’ve also created pages on the wiki for the first iteration at modelling the  individual processes, linking them down to a core set of application services, and over the next couple of weeks I’ll write blog posts for those.

Comments welcome to help refine this modelling effort.

How simple is “simple enough”?

Or “Simplifying an ‘architecture framework’ for agile strategy”

How often have you faced the situation where you need to get something done, and you know there’s all sorts of advice and guidance available, but you only have a limited time to implement something?

My current challenge is to relatively rapidly put together some strategic roadmaps for the systems in a business area.

In the past I’ve spent a very small amount of time studying TOGAF, just enough to appreciate the coverage of the model and to feel overwhelmed by the amount of material and unfamiliar language.

My current feeling is that it could serve as a guide for the piece of work I need to do, but I need to find a lightweight way through it.

Apologies in advance to all the experts out there, but I think the gist of what it says is:

  • Agree the objectives of the piece of work
  • Review the business environment and understand the drivers for change
  • Sketch out some possible changes to the business environment (e.g. process changes)
  • Review the impact on the systems and data, and sketch out some possible changes.
  • Review the impact on the technology, and sketch out some possible changes.
  • Decide on some interventions on all three levels that will address the drivers for change
  • Do some of them
  • Review and repeat as necessary

Seems logical, I’ll see how it goes – and if this is something you specialise in let me know if I’m missing something!

  • Follow Me

  • Subscribe by Email

    Enter your email address:

    Delivered by FeedBurner

  • Meta

  • Copyright

    • Unless otherwise expressly stated, all original material of whatever nature created by Julian Elve and included in this weblog and any related pages is licensed under a Creative Commons License.
    • Creative Commons License
  • Valid XHTML 1.0 Strict