mandag 19. august 2013

Personal Information Security; Baby Monitor

A video baby monitor in Texas was hacked via the Internet and abused by a very bad man:


If I connected security cameras at work to the Internet, authorities would come at me with full force. Surveillance is sensitive information and must be treated as such. One of the problems, then, is that most people are not trained to think of information security in their daily lives.

As a trained professional, I would look at the package saying "over the Internet", shake my head in disgust and put it back on the shelf - unless I was looking for a public web camera for Runde. Blinded by the convenience, however, a lot of people will cheer with joy for this invention, not realizing that they are opening themselves wide open to a malicious hacker ready to subvert their children.

The formula is fairly simple: Identify what is sensitive information (or sensitive access to your loud speaker as well, as in this case), identify who needs the information and the shortest route there, make sure you do everything you can to protect that channel in all nine aspects: Confidentiality, Integrity and Availability of Storage, Transit and Processing.

I will leave it for the reader as an exercise, before I reveal my own analysis of this system. 

mandag 22. juli 2013

Reflections on a Lean Hospital

Norwegian National TV recently broadcast a documentary about "The Health Factory" (film available to the world until August 19th 2013) where the first question was whether Toyota car manufacturing is the right ideal for healthcare.

Well into the program, former health care minister Bjarne Håkon Hansen presents the following scenario: He goes to Toyota, orders a specific model car he wants, colours, accessories. He is given a time he can pick up the car, and the car is ready at the time given. On his way out of Toyota, he calls the hospital, because he needs a knee operation. When he asks when he can have his operation, the hospital is not able to give him an accurate estimate. His conclusion: Norwegian hospitals have problems with logistics.

While I do not see any problems applying Lean principles in health care, one must keep in mind that there is a distinct difference between manufacturing and health care. And it is the same difference I experience between manufacturing and running a municipal IT department: It is not a production environment.

Manufacturing is a known process. It does not require diagnosis, and the risk of unexpected events are low. In contrast, a hospital will have a varying amount of emergencies, and many operations have a great risk of complications.

There is still value to be taken from Lean also in hospitals: Known procedures can be simplified. Quality can be increased. More things can be taken into consideration. Communication can be improved. However, it is important to understand that one must look at this holistically. The problems presented in the documentary seem to be what happens if top management attempts to implement Lean with a single focus on short term savings.

mandag 18. februar 2013

Policy as focus tool

I've been working for a while for an employer whose concept of "plan", "policy" and "procedure" is not only a foggy area through which one can not tell the three apart, but are further muddled by an unwritten current practice to which you are held responsible but not told.

The two first months of the year is spend writing document after document with "plan" in the title, albeit the contents range from a list of investments to policies, not to mention the "goal plan", filled with some vague unmeasurable purposes to which you're supposed to come up with actions whose effect may not be tested beyond "completed".

While some will call this "politics as usual" in the public sector, the vague framework causes real problems with communication between departments and expectations. In order to survive the work day, everyone becomes their own boss, and many of them decide to become the boss of everyone else.

As a rememdy for my own department, I wrote up a policy framework just for us. It's not big. It's based on the purpose of our department as described in the founding document: Technical support, maintainance and development projects. I use the broad definition of the term "development", as it not only includes in-house software development, but any changes to the IT system: Installation of new software, modification to the infrastructure, etc.

I elaborate on what we do in order to follow up on each of the main points, link in procedures where needed. Writing the document up gives a deeper understanding of what we do and what needs to be done. But for the team to really benefit, they need to understand and respect The Document. For all purposes, there is only one way to do so: involve them on a regular basis.

So this is our current schedule:
  • Every friday, we do a retrospect meeting over a pizza. The retrospect has several functions: 1) Status reports on the most important tickets and projects, 2) Feedback to team members, thus making them feel valued, 3) Solving unsolved puzzles by involving the entire team, 4) Lifting work off our shoulders, so that the weekend can be enjoyed better, 5) Raise awareness to other developments, meetings, system changes.
  • On the first work day of new moon, we run a Kaizen session. The department's policy framework is used as the framework of the meeting. We may not be able to go through the entire policy in one sitting. Giving this time, however little, helps the team own the policy. And that makes all the difference.
  • Status reports, policy changes, notes from meetings we have attended, etc, all go into a report headed for top management at the end of every month. This helps make our work more visible to top management.
It may cost us 10 hours of work per team member every month. Alas, from even the first meeting, you shall see the rise of morale. And from that comes an increase in productivity.

fredag 28. september 2012

eKommune 2012

Monday September 24th and Tuesday 25th over 300 souls - mostly IT personell, a pinch of sales people and a handful of municipal top leaders - met in Trondheim for the annual eKommune conferance. There was a great variation of talks, as might be expected. Most notable was possibly a mismatch between the view of central government and local administration about what needs to be done to optimize IT spending in the public sector.

Municipal CTOs agreed across the board that there needs to be architectural and protocol standards to facilitate integration, intermunicipal cooperation and municipality-to-state reporting. To achive this, we need action from central government. This is in tune with my article series about consulting in the public sector.

Central government, on the other hand, were afraid to touch anything that might reduce local self governance. One claim was that the differences between municipalities may be too great.


I got to chat with the CTO of a much larger municipality (withholding name to protect the CTO), and learned that we were technically not that different. In fact, we shared the same major challenge, which is a political challenge, rather than a technical challenge: How non-IT public workers - the very ones that we support - view IT and how methods of accounting IT costs obscure the big picture within the organization.

Indeed, I have had the same chat with the CTO of a large private company, who experiences the same organizational issues. It makes me wonder if we have ourselves to blame, in that we really are technologists, not politicians. Our message gets lost in our willful haste to get things done.

søndag 10. juni 2012

Games coding

A friend, whom I usually consider well educated in IT, came with a rather unexpected comment the other day. "I would like to know how to write games." What, any programmer can do that - albeit, there are many genres of games and therefore the required arts will depend greatly on the type of game you wish to create. However, if you're looking for a place to begin, here's the basic skeleton:
    while(game_is_running){
      controls();
      physics();
      render();
      sync();
    }
Each of the looped stages above will be greatly different from game to game. From the beginning of time, I can no recall any game that is not a combination of object oriented and map oriented - that is, the method you use to keep track of each element in your game is picked for CPU efficiency. You want to use the least amount of processing power possible.

Typically, the user and aliens are considered objects, though environment may be a map or object oriented. Controls() include receiving user input to manipulate the user object as well as any artificial intelligence you may need for computer generated players. In MUDs (broad sense), this may also include receiving updated data about another player.

Physics() should theoretically be the same in every game, except it's not. Is it a 2D or 3D game? Do we need gravity? Do we need gravity between objects? Object collition detection? Does anyone die? Is there acceleration going on, or are things moving at linear speed?

Render() should really be the same for every game of the same kind. In a 3D world, the world should render the same way at all times. It is common to create a rendering engine that is reused in every game from the same company. Except, of course, the technology changes and the rendering engine must follow suit. And when technology doesn't change, the programmer may still find things to do in a more clever way.

Sync() is possibly the simplest stage: The three previous stages will take different amounts of CPU time for every frame of the game. In order to get a smooth game, one must wait until the next "tick" of the clock - whether it is every 50th of a second, 30th, 20th or 15th of a second. Or even every second.

Within each of the stages above, the details become a science of its own. It's not tough, though, you just need to break it down to bit sized chunks.

mandag 21. mai 2012

Image zooming

A friend of mine posed the following problem to solve for his VB-in-Excel application:

In a view of 846 x 660, an image is rendered. By clicking anywhere on the image, zoom is multiplied by 1.2. However, and this is the important part, the part of the image clicked on shall remain the center of the zoom and remain in place of the part of the view clicked - i.e. directly below the mouse.

Since I'm not a VB-coder, my reply is in C-like quasi code.

Input data


To solve the problem, we need to be absolutely clear about what the input data is, which in turn is dependent on the source of the data. We start off with the follwing information:
// STATIC DATA
int imageWidth, imageHeight;              // Size of source image
int viewWidth=846, viewHeight=660; // Size of onscreen view 

// VARIABLE DATA
// Position of view/sliders on the projected (zoomed) image
int scrollX, scrollY;
// Size of projected (zoomed) view/sliders
int scrollWidth, scrollHeight;
// Bar/slider size represents the view compared to projected image
int barWidth=viewWidth, barHeight=viewHeight;
float zoom=1; // Current zoom
Then you have the mouse click. We need to know two things from the click: Visually where in the view you clicked (viewX,viewY where top left of view is 0,0), and what position this represents in the image (imgX,imgY). The image coordinates can be calculated from viewX,viewY this way:
int imgX=(viewX+scrollX)*zoom, imgY=(viewY+scrollY)*zoom;
However, in my friend's case, the input data had the entire zoomed image as its reference, so top left of entire zoomed image represents 0,0 and bottom right (with sliders also bottom right) represents scrollWidth,scrollHeight. Hence, the parameter representing the clicked position (clickX,clickY) is the position in the view (viewX,viewY) PLUS the position of the slider bar (scrollX,scrollY).

Since we need to know the actual visual position on screen, relative to the top left corner of the view, the two coordinates must be calculated as such:
// Position unzoomed to fit zoom=1
imgX=clickX/zoom; imgY=clickY/zoom;

// Pos. shifted to visual position
viewX=clickX-scrollX; viewY=clickY-scrollY;
User control

New zoom is calculated per policy defined by my friend - basically:
int zoomstep=1.2;
if(leftClick)zoom=zoom*zoomstep;
else if(rightClick)zoom=zoom/zoomstep; 
Calculating new scroll bars


We now know the new zoom and want to render the view with (imgX,imgY) located where the mouse is on screen (viewX,viewY). First step is to tell the scroll bar control what the new sizes are:
// Size of projected image changed with zoom
scrollWidth=imageWidth*zoom; scrollHeight=imageHeight*zoom;

// Size of bar/slider doesn't really change unless you change size of view
barWidth=viewWidth; barHeight=viewHeight;
If we set scrollX to imgX*zoom (image coordinate projected to new zoom level), our point ends up in top left corner of the view. However, we want this point at viewX,viewY, so we must offset the X-coordinate to the left, i.e. subtract the viewX,viewY coordinate:
scrollX=(imgX*zoom)-viewX; scrollY=(imgY*zoom)-viewY;
Edge adjustment

Unless we want to scroll off edge, we may need to adjust:
if(scrollX<0)scrollX=0;
  else if(scrollX+viewWidth>scrollWidth)scrollX=scrollWidth-viewWidth;
if(scrollY<0)scrollY=0;
  else if(scrollY+viewHeight>scrollHeight)scrollY=scrollHeight-viewHeight;
Rendering

If you need to render the image manually, the typical approach is to find the source rectangle within the image and project it to the full view.
int left=scrollX/zoom, top=scrollY/zoom;  // Reduce position to zoom=1
int right=(scrollX+viewWidth)/zoom, bottom=(scrollY+viewHeight)/zoom;
Then complete the operation using StretchBlt (if in a Windows development environment) to stretch-copy the rectangle from the source image to your new view context.

Other

Feel free to ask for further calculations or other parameters in the comments. If the above code fails, it may be that you have other input parameters or need to calculate some other numbers than what this article has attempted to convey.

lørdag 10. desember 2011

So what happened to trollsilm.com?

I was busy moving and spending time in hospital and preparing for the birth of my third child, all at the same time. So trollsilm.com renewal slipped, and soon after someone jumped on to it. I have tried to get in touch - after all, there should be a prize tag to get it back - but to no avail. Hence I have registered trollsilm.org and will be moving there soon.

If anyone has the time, determination and possibly money to bother the heck out of the squatters, feel free:

From http://www.ip-adress.com/whois/trollsilm.com
Registrant:
Above.com Domain Privacy
8 East concourse
Beaumaris
VIC
3193
AU

Tel. +61.395897946
Fax. 

mandag 25. juli 2011

The fertilizer man

I can not give this man a more fitting name. Some will call him "the devil" or "low life" or "insane" but after setting off a car full of fertilizer bomb, and knowing what that smells like, I will always think of him as "the fertilizer man" no matter how much damage he made and how many lives he took.

While most of the world seems to have arrived at logical conclusions around the entire incident, I have come across some - I'd almost say appologists - who seem to have failed miserably at their quest for logical reasoning as the perpetrator himself. From the point of view of the Fertilizer Man himself, the idea that multicultralism is destroying Norwegian culture, I beg to ask the following questions:
  • If the big enemy is multiculturalism, why kill Norwegians?
  • If the humongous problem is the destruction of Norwegian culture, why kill Norwegian youth?
  • If the big fear is massacres performed by foreigners, why make it so blatantly obvious that the self proclaimed protector of Norwegian culture also is the greatest mass murderer of those who could bring Norwegian culture forth?
  • And if protection of Norwegian culture was so important, why so much fear of the smallest group of cultural immigration, when it is so blatantly obvious that the greatest threat to Norwegian culture is Mickey Mouse and Ronald McDonald?
The idea that he blows up some government buildings - sure, I can see that happen. Happens all around the world from time to time. Many people have their secret wish to blow up the parliament every time some strange taxation law or other regulations interfere with their daily lives. The Fertilizer Man got that one down. Fine. You're angry with government, you blow up goverment, I get it.

But shooting youth who have barely reached legal age - and some of them not even that - is just an appalling act of evil. And a rediculous one at that. You first claim that non-Norwegians are a problem, and then you go shoot Norwegians.

The only logic to this is the idea is the "monoculturalist vs multiculturalist" scenario. So the monoculturalist went to war against the multiculturalist. And that's where some of foreign mass media have picked up.

Russia Today is repeatedly reporting about a "multikulti fail" in Norway:

Even the title is wrong, insisting that he turned "against his own." He did not. In his world, he was the monoculturalist against the multiculturalist. That's where the "us vs them" was.

Taken out of context is the Norwegian border closure. While they are still investigating the possibility of the Fertilizer Man not acting on his own, police want to make sure they know who leaves the country. This, however, is being portrayed as a sign that the European Union is falling apart in distrust.

To make sure everyone gets the problem with multiculturalism, Russia Today interviews the Spokesman for the Union of Russian Communities in Sweden, who apparently met the Fertilizer Man in his youth:


His opinion is clear. Multiculturalism is bad, he says. Spokesman of Russian Communities in Sweden. What are you doing in Sweden? You're not Scandinavian. You're a spokesman for the Union of Russian Communities. Preserving Russian Culture. In Sweden. Side-by-side by with Swedish communities. What do we call this, again, when several cultures live side by side? Multiculturalism?

It is obvious that Russia and Israel are vested in monoculturalism and therefore support this view. Since the Fertilizer Man was a monoculturalist, and the media of both countries blame multiculturalism, they are fairly appologetic: It wasn't the Fertilizer Man's fault, he was forced to do this by the multiculturalism that wouldn't let him sleep at night.

Again, if blowing up the government in protest was all he did, fine, it's a protest. Absurdely aggressive to be in Norway, but it's a legit target in war, and to him, this is war. Youth camp? Sure, it was a political youth camp, but still.

With all the talk of "multikulti fail" and the preservation of Norwegian culture, I can't help but think of what Norwegian culture has been for the last few thousands of years. As a friend in Atlanta once pointed out - our genes look so incredibly diverse to be such a small country.

Guess what, even our genes are multicultural, as we have been trading, importing culture, slaves and wives from large parts of the world since at least the viking age. And we traded and lived side by side with the Sámi people, even paying them local taxes whilst visiting anything north of Trondheim until Sápmi was annexed by the king of Sweden.

Multiculturalism is nothing new in Norway, it's monoculturalism that's new. The strange, suspect idea that we can preserve a culture that has been in constant change since before our written history. And people like the Fertilizer Man are trying to kill Norwegian culture by the sword - or rather by dung heap.

mandag 6. juni 2011

Who needs sticky yellow paper?

Post-its are all too often used to keep your username and password safe and secure to your monitor for everyone to see. As ICT Leader, I rip these away faster than I see them. Even if it should be at a publicly accessible airport terminal - which is probably why an airport has found a way round the "missing post-it" problem at their self service check-in terminal. (IMHO, This photo should be submitted to The Daily WTF)


Photo/observation tweeted by Per Thorsheim

fredag 3. juni 2011

Mission completed

I can not say it has been quiet here in the home of the trolls. While troll mom has been dealing with the troll kids, I have been away completing a decade old dream: To bicycle from Paris to Amsterdam. Indeed, it's the European version of my 1997 bicycle trip from Montreal to Toronto, with a few more personal touches and detours added, not to mention time. Over a 12 day period, I bicycled 900 km, which means an average 75 km/day.

Accomplishing personal goals, I believe, is vital for your psyche. It is easy to see how corporate support to achieve personal goals could increase morale - That is, if my dayjob paid all my hotels, spend work hours planning for the trip, etc. And certainly, had this been part of my job, I would probably spend work hours finding similar businesses to hook up with during my trip.

But be careful: It would be tempting to upgrade my bicycle to an electric one. It wouldn't be the same. I would spend more time stopping than riding, and I already spend about half my bicycling time doing other things than bicycling. It would feel more planned and with less freedom.

In short, as long as everything was in my own hands for the entirety of the trip, I was energized by self realization. This, in contrast to my trip to New Zealand about ten years ago, when I had this "wow, how did I end up on the other side of the planet, how cool is that?" form of self realization the first couple of days until work wore it off.

So the key leans more towards self realization than accomplishing the actual goal. In other words: support, but do not interfere. Or in the words of Dan Pink: You probably want to do something interesting, let me get out of your way.

Completing my mission motivated my wife to bake :)

mandag 25. april 2011

Pending name change

For a while, I have known that Agave has trademarked the name sqML for a product that is similar to (but not nearly as functional as) Trollsilm SQML. This has not been a problem, since development of Trollsilm SQML has been resting on a shelf for the last six years.

As I have pulled the product off the shelf, blown the dust off and started development again, I now see this as a pending problem. Not just in the form of possible law suits if I continue to use the name, but in the form of confusion between the products.

The new product will be open source, and it would therefore be fitting to open source the naming. SQML change 0.8.1 is therefore the actual name change, which will also affect the default extention used on the script/template files.

Suggestions will be accepted as comments to this blog post or to the facebook discussion until May 12th. As I ride from Paris to Amsterdam, I shall ponder the results.

søndag 24. april 2011

Unlean branch blocks road

After finally fixing up my bicycle for the season and going on my first proper morning trip (6.4 km), I encountered this branch half way:

[Photo of cut off branch locking the road]

My initial reaction, of course, was the knowledge that this branch would never have been "lying around" on the road for motorized vehicles. And so my brain started working on what process might be broken here, realizing that the lack of process might be the reason why the branch was still there.

I could go on about how counting the number of branches cut and then the number of branches cleaned away would make it blindingly obvious that one branch had not been cleaned away. Then again, just looking at the street should suffice.

But then, this was more likely the work of kids pulling a branch out, purposely blocking the road, long after the branch had been cleared. As such, the solution would be to bring the branch home, chop it up and dry for next winter.

tirsdag 19. april 2011

Using SQML in the IT department

Ordinarily, on doesn't use home grown technology at work. "Who is going to maintain it if you go?" is the typical caveat. "Let's use open source instead," says the government. Well, guess what. Open source technology is home grown technology. Mostly.

So I started implementing eTicketSupport in SQML. I mean, the application is already up and running, all I'm doing is change the gateway to it, using SQML to modify the database directly through my own GUI.

Points I've implemented so far:
  • Support technician may now respond "as user", so emails sent directly to the technician may be copy/pasted to the ticket as if the user had sent his/her email to the support address.
  • Response by email is optional.
  • Private messages are embedded as ordinary messages, though visible only to IT department. This way, it is easier to follow how these messages came to be.
  • Added another table with template responses based on ticket category. Once category is selected, you may click on template, which then gets pasted into the response edit box.
  • Users log in with their AD login information instead of ticket number+email address. Session is stored in cookie and valid for a week after last access.
  • Once logged in, their first view is all open tickets, followed by tickets closed the last 7 days.
  • Department leaders and super users get to see all open tickets within their own and all departments under them, and are allowed to add more information and follow what's going on in their own department.
  • Archive of old tickets on separate tab.
  • Integrated with overview of who works in your department and ability for department leader and superuser to add "new user" requests and reset passwords.
The code for this shall be open sourced soon.

And if I go? Well, I will continue to develop (it is open source), and I may give support as a consulting job - as will probably many others. And either way, this is merely a new entrance to existing systems. All I have done is to make it more efficient.

mandag 4. april 2011

Polishing old gems

As I have done a few snippets of code here and there to make my life a little easier, I still have not found the ease with which I did things when I used my own Trollsilm SQML, not to be confused with SQmlTM - Which reminds me I should change name of the language while I still have the chance.

I wrote the SLOB database in 1999, the markup language in 2001, and stopped developing it ca 2005 due to time constraints. The tool is still being used by an ISP in Norway, hoping that development will commence. Because just like myself, their experience is that they just haven't found any alternative that allows you to whip up full blown web applications in such a straight forward and intuitive fashion than this.

This might sound like bragging, but as I am now faced with new challenges at work, I long for this tool. I looked up "the competition" (Ruby-on-rails), and found out that they were not really competition after all. Does SQML - or should I call it "TrollML?" - have the right to live again? Should I spend time continuing its development?

You betch'a! There are caveats, of course. Currently, the SLOB database is the one getting the most out of the language. I need better SQL integration that makes it as easy to deal with mySQL as it is to deal with SLOB. And most of all - an Apache module release. I have a good list of things that need to be done, and in which order. And most importantly, I can feel my fingertips getting tingly in anticipation to work on this project again.

Business model? Open source. It's not the technology itself I wish to monatize on in the future, but assisting people who wish to use it.

onsdag 30. mars 2011

PK Scheduler Diary

I've been working on a scheduling principle for Personal Kanban.

Say what?

A way of scheduling my Personal Kanban. Kind of mixing my PK and my calendar. And make it all portable. There's a story behind it.

In the beginning, there was Personal Kanban

It all started with my experimenting with PK at work. Obviously, as the team leader, I have different tasks than the others. I do things that don't go into the support system. And PK in its simplest form gave me tremendous stress relief. Even though I know there is a backlog, I can easily see how much I have already done today, not to mention this week. Tear down finished tasks on friday for a retrospect. It worked quite excellent - for the first couple of weeks.

Then came the questions. "When will this task get priority?" "How about this task?" The concept that I'd pick the highest prioritized tasks every day was not a good enough answer. Some tasks might never get picked that way. And I did not get a proper overview of what needed to be done when, even when the dates were on the cards.

Then came the calendar

So I made a scheduled version of the backlog. That is, I made a small four week calendar with space for one card each day. Any task put into the calendar will be the main task that day. Anything put on the calendar will be processed the day that has been scheduled for it. I will also not promise that the task will be processed any sooner - so it can safely wait until that day.

If I have any spare time after the main task, random events, random support calls, scheduled and unscheduled meetings, I pull new tasks from the unscheduled backlog instead of the calendar.

When a week has been cleared, that column is immediately reused for appropriate tasks from the backlog. The system works like a dream, and I go home with the knowledge that everything that I promised has actually been delivered.

Freedom of movement

Then a virus came along, and I had to work from home for a while. This promted the problem of only having physical access to my Personal Kanban and scheduler. I would drop by the office once in a while to get stuff I needed to complete tasks at home, and update the scheduler. I brought a bunch of cards with me in my meeting book.

It doesn't take a rocket scientist to find out that the easiest way to carry my Kanban along was to use the first couple of blank pages as a portable Kanban board - of which I am not the first person to reinvent.

Except, I used those pages for the scheduling, and usually use the monitor for the board itself. Notes stuck on the left side are ready, below the screen is current, and completed on the right. At the end of the day, stick completed task in meeting book for future retrospect.

Combine with note taking

I delegated a meeting to the apprentice. I really don't expect anything ground breaking to come out of the meeting, but I believe the apprentice can learn a bit. So I gave him a link about note taking techniques. My favourite is a page split in two, left side for notes, right side for actions. Alas, my ordinary meeting book does not feature this layout, and although I could easily make this design by hand, I decided I just wanted something smoother.

Although the notepad generator is great, I wanted an entire book of these - one notepad per day. I believe we call these diaries. And indeed, the seventh sense diary that the municipality has bought features this layout.

So how do I combine this with my scheduled Personal Kanban? Easy! Put future tasks and relevant information on yellow sticky notes. Put them on appropriate dates. Left side (note side) I put in my appointments and other important information about that day. Right side goes for the important action item for that day. When the day comes, the page is my "ready" column. The monitor is still my "go" column.

When a task is completed, I use the notes section for the retrospect in addition to meeting notes - and throw away the used note. The right hand side is then filled with information about the new tasks required. At the end of the day, I produce new sticky notes for the new tasks that need to be scheduled on a different day.

For about two seconds, I wondered why I didn't just use the diary as a diary and write the appointments and todo-lists directly on the selected days? Before the two seconds had passed, I realized that the sticky notes represented a floating possibility of a future, plans might change, and the sticky notes make it easy to move them around easily. Anything written directly on the page, however, becomes the log of what has been done, learned and decided.

søndag 27. mars 2011

The wrong script: UC as a replacement for process

Conference room at Hotel Ivar Aasen

I went to a meeting with the municipal where a local service provider presented a telco-side UC solution. There was much to like, of course. To present their case, they had a video from a make-belief architecture company. The script went something like this:
    Someone about to go to a meeting with a client looks through the project drawings, believes that the drawing is made by an architect who is currently on another phone call. So he calls up someone else, they discuss the content and whether it is possible to change the roof angle, add the carpenter to the call even though he is out in the field, the carpenter believes it is doable, but will cost more.

    After a bit, the estimate comes back from the carpenter, and the project now costs 12% more, though everyone in the project group goes for it. The boss, of course, is on vacation, and has this strange feeling that he is behind on the project and pulls a spontanous video meeting to get updated about the progress and why it is now 12% above budget. He feels at ease after the meeting.
While this gave a wonderful display of how teleconferencing has been made so much easier, I could not shake the feeling of something being terribly wrong in this picture. It was just the wrong script. I shivered as I started to count all the wrongs:
  1. The drawing should have been marked, so you don't have to ask who drew it - you just look it up.
  2. The team is presented as a project team. It should be obvious to everyone on the team who does what, not to mention who made the drawing in this specific project. Why do you put someone to meet a client, if he doesn't know everything about the project already?
  3. The request for alteration to the plan was taken from thin air without first talking to the client, and for no obvious reason. Obviously, alterations are better discussed with the client. Keep them in the loop!
  4. Everyone keep interrupting eachother for no obvious reason. After all, none of the information required were critical to the continuation of the project - except perhaps the financing bit.
  5. For every meeting in the project, short and accurate notes were made. Yet, the boss decided to call in for a video conference instead of reading the notes. So why, exactly, were notes taken, if not for someone to read?
I envision going to the client meeting, mentioning the angle of the roof, telling that it can be altered and query if this is something to spend time on. If yes, then go ahead, otherwise all this work is for naught.

Alterations like these are routine for an architectural firm, there are already processes in place for such. Indeed, I have been in such meetings (as a client), and they are very structured.

The video presented the alteration as an extraordinary event, where people had to drop everything in their hands to deal with this one thing. Or in other words, technology helped them interrupt current work in progress for something that should have been dealt with by the proper processes and proper documentation that the firm did not have in place.

I am not against UC, but it is not a replacement for proper work practices and documentation requirements.

onsdag 23. mars 2011

CIPA part 5: National solutions

Consultants in Public Administration: Part 1 - Part 2 - Part 3 - Part 4 - Part 5

Employees of the Norwegian Wealthfare Agency (NAV) complain about how their systems are outdated. Some must even "learn DOS commands", which we know is the umbrella term for black windows with white text where you must actually use the keyboard.

NAV is a "recently" established cooperation between local and state government bodies. Some of the IT resources are owned by the municipalities, while others are owned by the national government, and there is little information being passed between these as a result of content rights and personal data protection directives. Setting up a NAV office requires some planning to enforce all the information flow/blocking policies. Even copy/paste is disabled across the platforms, so you can't copy information between the municipal and the national systems.

And this is where the pain begins.

As each municipality runs their own systems, NAV must attempt to integrate all of them into the big conglomerate. But neither state nor NAV has the authority to override what is installed at the local municipalities as long as it conforms to certain integration standards. Because if national authorities dictated a shift of technology, then national authorities would be liable to pay the bill. In the short run, the cost of integration seems to be smaller than the cost of conversion. By publishing the integration interface, much of the integration cost is now pushed over to the municipalities as part of their annual software license fees.

The cost of convertion, as such, is what we my refer to as "the cost of exit." As each system has an entry and a maintainance cost, there is also an exit cost. What does it cost to change system? And what system should be our standard? After all, setting a national standard would kill the business of all the other tailored government system developers. Some commercial actor would be able to monopolize. So how do we get out of this?

In 2006, the Swedish police turned to an open source platform and hired its own software developers to build their own mySQL and JBoss based information system. From this, they gained tailored software, a flexible system that can quickly be altered to reflect the needs of the police, full ownership of how the system works with their own data - and economically? The project pays far more than the investment in software developers. Reduced licensing and consulting costs equals approximately 400 fully equiped police cars per year.

A similar approach may be used in other government bodies, where specific tasks have been defined. This is what you do, let's all do it on this one system which we all own. If a law changes, we can change our own software - or pay huge sums to 4-5 different software companies to modify their software for the new law.

And one could take this a step further by setting a national standard for ESB - or would that be a GSB (Government Service Bus)?

Consultants in Public Administration: Part 1 - Part 2 - Part 3 - Part 4 - Part 5

søndag 20. mars 2011

EU Retention of Protected Data Directive

The Norwegian government has been discussing the Data Retention Directive for years, and the government has been fairly split about it. So split, in fact, that it has been declared that the vote is now dependent on one single party in the right wing. And their verdict just came out: "Yes, we want the directive, but slightly modified." (The no-side, obviously referring to the Data Protection Directive, which they claim is at odds with the DRD.)

While I'm all for solving crimes and preventing terrorism, I try to be a little bit realistic. Because logs of IP traffic, SMS contents and email headers are at best circumstantial evidence and will be difficult to hold up in court. Why? The data logged is about the communication between devices and does not guarantee the identity of the people using them.

The information might be interesting in terms of indicating where to look, as a tool of finding potential clues, but it is not real evidence in itself. Similarly, I once received a ticket for passing a toll road without paying - except both I and my electronically identified car was some 100 km away at the time - I had a time stamped photo where I was at the time.

How could this happen? The car that passed the toll road carried the same letters and numbers on its registration plates as my own car - except his registration plate was from a different state, and the system didn't pick up this tiny detail.

So imagine this going a little further - for some tougher crime: Someone steals a gun from the local home defence, shoots someone, and drops the gun. Police picks up the gun, reads its registration number and uses this as evidence that the local home defence did it.

As for the Data Retention Directive? Just because someone hacked into my Wifi doesn't mean I started the video conference that was logged. And no, I was not even near Düsseldorf during that bank robbery - my cell phone was there, yes, it was stolen! And I did not sent that text message, a friend "borrowed" my cell while I was in the bathroom.

The DRD does not indicate any automated analysis of the data, which would have some kind of use in detecting "suspicious behaviour" - whatever that is. There will be enough arguments that illegal activities can not be properly detected by automatic data analysis - though I suspect the most resoureful governments have been doing this kind of analysis for ages already.

Actual value is therefore limited to following circumstancial traces - akin to the situation you have when analyzing every finger print in a bank after a bank robbery. And at that point, you already expect the bank robber to wear gloves.

Real world results from the directive?
And in Norway? The final decision is scheduled for April 5th, where the only two parties that want the directive are expected to vote under the whip. And if they don't vote by the whip, the directive won't pass.

It's a bit scary to see that the secret service sees the directive as their "most important tool."