IT Meeting No. 2

Date: September 30th 2006

Attendants: Jonas, Anders, Bo, Peter

Agenda

Discussion of the ItMeeting-paper from the first IT meeting, urgent needs and scenarios. Focus – comparing the "urgent needs" of Creation with current and planned improvements to the current system at Homebase.

Specifically, the meeting did *not* focus on more long term strategic issues, only what sprung from the concrete "urgent needs" of Creation and ideological standpoints of Jonas.

Urgent needs stated:

Our current system/platform and the urgent needs:

Address

Jonas is working on a shared address functionality generally for Homebase. The task set by KP was for a shared digital address book, equally accessible by all KP members. The actual goal set is to replace Karins Rolodex with a digital solution usable by both Karin, other members of the staff, and remaining members of Homebase - which implies demand for extremely simple use and multiple levels of access control. The solution will be an LDAP service accessible from most existing email clients, and editable from our current webmail. The work is severely delayed, and only promise is that it will be ready "mañana".

Creation has more advanced urgent needs than shared, access-controlled addresses and address lists. Multi-dimensional "tagging" of each address is required. Exemplified by needs like:

The above mentioned functions will alove us to use the address-DB as a repository for sharing knowledge about external lecturers, their price and their strong and weak sides. To keep track on contact-persons and to mark te same person for different mailing-lists, including to avoid to send mails to people who have explicitly asked to be removed from our mailing-lists, etc. In other words, we need to be able to use the address-database as a professional- though low-end - Customer Relationship Management System.

The urgent needs of Creation can be fulfilled either by a custom application, which either access the LDAP database or uses its own back-end database. It is simpler to setup such application using its own database, but then synergy with other uses of simpler data is lost - i.e. addresses of external lecteurers used both by Creation and for student projects needs to be maintained twice, instead of comments on payment and pedagogical qualities being staff-only add-ons to same resource.

Such custom application is most likely satisifed by either of the collaboration systems described in detail below.

An alternative to central client-server addresses (pointed out by Anders and originally proposed by Bror) is "the vCard approach": Rely on public web-based adress services and peer-to-peer meetings to exchange selected info between each personal address book.. Both Jonas and Peter agrees that it only poorly satisfies what is possible by a central system.

Access control

Jonas is not against access-control, but is strongly against implementing access-control in systems that are not designed for it – i.e. our wiki is not build to maintain access-control facilities, and though it is technically possible to implement, it will be as a hack, thus risking security flaws and a higher maintenance burden.

An alternative to access control (pointed out by Anders and originally proposed by Bror) is "the community approach": Rely on resources being personal and shared by each peer collaboration. Both Jonas and Peter agrees that it only poorly satisfies what is possible by a central control.

Calendar functionality

A web-only calendar functionality similar to what has existed in the past is easily implemented, but considered inadequate for today's needs - both those of Creation and of other Homebase users. The main issue is syncronisation - both syncronising settled events with personal applications like iCal, phones and PIMs, and negotiating proposed new events like meetings. Both types of syncronization is considered realistic only in a "client/server" setup (with applications talking to a centralservice, as opposed to a simple web-based system).

Jonas is working on a shared calendar functionality generally for Homebase. The task set by KP was for a KP-only system but without (explicitly expressed, at least) further access control. The actual goal set is a system with access control, thus usable both by Creation, KP, homebase and cross-group projects. Initially the system is accessible only through web, but the database back-end is modelled after a growing consensus within the Free Software movement, making is viable for converting into a tighter integrated collaboration system - wether free or closed source. The solution is based on same technical foundation as the address system - it will be ready "mañana".

An urgent need for Creation is the syncronisation with personal calendaring tools, which is not part of the project planned by Jonas (only as a future improvement).

The urgent need of Creation is most likely satisfied by either of the collaboration systems described in detail below. The two last Free Software collaboration systems listed is an implementation of the "future improvement" of Jonas' plans.

An alternative to central client-server calendaring (pointed out by Anders and originally proposed by Bror) is "the iCal approach": Rely on public web-based calendaring services to exchange selected info between each personal calendar. This works currently for Mac, and can be implemented for both Windows and web too (but will most probably have issues when mixing different kinds of clients). Both Jonas and Peter agrees that it only poorly satisfies what is possible by a central system.

Shared resources

In addition to the above resources, which are by nature highly structured, there's also a lot of "chunks of data" that does not by itself invite for structured organisation, but needs to be anyway.

Learning Zone is working on an optimal (single-dimensional!) organisation of their documents. When this is finished, Simon could work with Creation to create a structure for their materials.

This would somewhat satisfy Creation, but would be limiting for their work. What they really need is being able to apply multiple "tags" on each resource, and navigate through the resources by each or a combination of such tags.

An alternative to multidimensional tagging (pointed out by Anders and originally proposed by Bror) is "the Google approach": Rely on search tools built into the users' desktop to find relevant info. This works currently for Mac, and can be implemented for both Windows and web too. Both Jonas and Peter agrees, however, that it only poorly satisfies what is possible by tagging the resources themselves.

How to move on

We had a brief discussion on how to move on from here…. Basically this is a discussion about: - staying with our current platform and develop it within the frame of possibilities it offers - adding another platform/system to our current platform, that immediately could satisfy a bigger part of the needs defined by Creation. This could be as an example an Appleserver, a Lotus Notes platform, a Microsoft Exchange server or other system/business system with parts or all of the functionality defined in the urgent needs analysis

Bo expressed:

That our current problems with the internet connection and internet stability is another problem that shall be solved no matter what – it is not part of this discussion, but is an underlying problem that will be solved anyway.

That he finds the best solution would be to stay within our current system/platform. And that a primary focus is that the system shall be user friendly and easy accessible in terms of interface.

That he is doubting that applications like shared calendar systems will work in the KP culture, because they require that everybody are recording their appointments in the system (electronically), and that some of the KP staff don’t use electronic calendars but paper calendars

Anders expressed:

That we should start by solving our problems with a stable internet connection (see Bos comments about this being a separate issue, that is outside the scope of this discussion and shall be solved anyway)

That he would prefer that we went for Bror’s solution (ANDERS PLEASE ELABORATE HERE)

That he was reluctant to be responsible for administering another server/platform that he is not educated in, and if this should be the case, that her would prefer an apple server compared to a Lotus Notes server.

That we basically don’t need structure to be able to find documents, because we have the search engine Spotlight that is a build-in part of the Mac OS, which means that you can just go to tha archives and start writing a word you are looking for, and the Mac will show you the relevant documents on the fly. Works both on local Macs and fileservers/shared archives

Jonas expressed:

That it would be realistic to expect that the address application (LDAP engine, Karins Rolodex) is “just around the corner”, but it will not satisfy the recent requirements from Creation

That it is possible to make a calendar solution as a web-based solution, meaning it will not be a client/server functionality, meaning that all appointments shall be created and maintained in the web-application and not synchronized with local calendars – we would have to be more specific on our requirements for stuff like handling of free/busy time, etc.

We could implement an added server if we want our creation-defined needs met, and it could be whatever will satisfy our needs, i.e a Lotus Notes server, an Apple server combined with .Mac license for all staff, etc. We would have to regard this as apart form Jonas’ services, and we will have to be responsible for the maintenance our selves. Further we will have to decide on which system should be the “Master” and which the “Slave” (explain: If we both have the electronic LDAP rolodex AND a Lotus Notes customer address application we have to decide which one should update the other)

Deadlines for both the LDAP rolodex and a calendar application is best defined as the Spanish “Mañana”, it could be soon, but no promises can be made.

Peter expressed:

When we look at the cost/benefit analysis for our current system vs. a Lotus Notes solution, the Notes solution wins on the “brain-matter” i.e. Price (even though Jonas stated that he made a calculation error in the pricestatement, so if he makes address and calendar applications it is a total of 20K, not 40K), on functionality, on strategic possibilities i relation to create synergy and sharing with other KP programmes, and in future flexibility. The current solution/current platform wins on “heart-matters” and feelings because the philosophy is open source, freeware

So how do we carry on,( Peters personsal comments):

I think we need assess how and if the staff would agree on using the functionality or parts of the functionality we are talking about in the solutions to cover Creations urgent needs.

If the staff don’t want to use some kind of electronic calendar function, then implementing it will be WOMBAT (Waste of Money, Brain and Time) anyway. Similar with more structured database applications for shared resources.

IF the staff want to comply with such application types, we can then assess the pros and cons of 3 relevant systems, i.e Jonas’ applications, an Appleserver, Lotus Notes, compared on functionality, price and maintenance

And when we have taken a decision, the decision will determine the timeframes and deadlines possible.

Collaboration systems (opinion of JonasSmedegaard - delete this paranthesis if others agree!)

Current system at homebase is a set of tools, all (or most - wiki and mailinglist are apart) tied to same user accounts and access control system, but *not* interacting with each other.

A common need among the urgent needs of Creation that are not fulfilled by the current system is such interaction between the tools, and between tools and its access controls.

The following approaches all solve the needs, but they are at the same time "stepping on each others toes", as they require a central role for all of its users to truly succeed. This means we need to make a choice of a single path to take: Testing out multiple concurrent paths will cause them all to fail.

The 3 upper approaches can be implemented rather fast, but runs as a separate (Windows, MacOS X or Linux) system, leading to added technical maintainance (by new staff, either hired or outsourced), and (user visible!) multiple user accounts.

The last approach is slow to implement, but requires no added maintainance, uses existing technical staff, and gives both users and technical staff at the organisation time to adapt slowly to smarter ICT.

Homebase: ItMeeting2 (last edited 2006-10-12 09:37:24 by JonasSmedegaard)