The war is on

Two facts combined in my mind yesterday:

• After installing some Google software on my home machine, I'm experiencing Internet Explorer crashes. I'm aware that time correlation is not causality. Not worth figuring out though, I still have Firefox running.
  
• I've read on slashdot that Google is scrutinizing Microsoft Vista for obstructing fair competition, notably on Google Desktop Search (which is a great tool, IMHO).
  

The war is on. Battleground is right on our desktops. The stake is our attention (better than fighting over oil, probably ?) and the corporate income it generates. A few more lawyers earning a living on the beatiful US West coast.

Technical architecture though: if you support plug-ins from other vendors, how do you prevent them from maliciously crashing your process ? A quick solutions brainstorm:

• Run plug-ins in separate processes or terminatable compartments and communicate via your favourite IPC or cross-compartment mechanism. May get technically complicated (depending on the technology you're using).
  
• Run only thrustworthy plug-ins using authenticated certificates. Will get you in trouble with antitrust authorities. May be not so smart if you want to have maximum accessibility for plug-in developers.
  
• Combine both: use terminatable compartments for thrust-unworthy plug-ins. May complicate the plug-in interface as well, because the actual interface protocol must be transparant to the plug-in developer.
  

Anyone any bright ideas on this ? Or am I providing more bright ideas to Google to help them make Microsoft software crash :-) ? And will any of both sides bother to sue me over that ? Uh oh ?

Let it go and buy in time

An additional intention will be to write an article on average twice a month. Since I wrote 3 articles in May, that target puts me in the comfort zone for a few more weeks.

A question to all architects out there: how large a proportion of your time do you spend on communicating with people in development projects, IT management, business management and business application owners (in my definition of the term usually not managers) ?

My rough estimate is: about one third. Not all of this is architecture related. Other subjects are IT governance, development process, operations & support process, project management and perhaps even more important, the emotional state of people connected to the projects. Somehow these subjects are hard to separate. Not that I mind, ignoring these subjects would lead to failure in architecture and vice versa. And I like to think I'm a warm-hearted person.

Over the last month, we performed a self-assessment of the ICT department. I asked everyone in the ICT management to self-assess the department on all of these subjects, positive sides as well as sides up for improvement. The result are organized by topic, and then discussed. The exercise can be considered a success for these reasons:

• It lets go some of the tension present in the department by giving everyone the opportunity to speak out. In a somewhat secured environment.
  
• It informs me about the subjects on which opinions meet, and the subjects on which there is difference of opinion. This is an important factor to verify the buy in.
• It helps to set priorities for the evolution and improvement program. The other dimension to consider is maturity levels.
  

This is not a bragging article. I was, in fact, unsure whether I could pull this off. Although I've seen some great examples from other people over my career so far, getting the best out of other people isn't my greatest strength. Some of the factors that contributed to the success certainly were:

• Persistent communication, ensuring response every step of the way and encouraging continually the participants that needed it.
• Framing the exercise really well. I explained the process we would follow in great detail, so everyone knew what to expect. Everyone knew how personally traceable their contributions would be. I explained the attitudes I expected in great detail as well, stressing them each step of the way. Fortunately, almost everybody respected them and there was no need to intervene. I also improved my templates once more (anyone interested ?). Still, categorizing the remarks correctly was a difficult task for me. There were 102 remarks in total.
• I could count on the contribution of some experienced and friendly colleagues to guide the discussions.
  
• And last but not least, I took the time to get to know the working of the department, verified some of my perceptions by the numbers, and got to know the people in the department personally before I undertook the exercise.

This is perhaps a personal factor, but I'm not that good at immediately responding when someone does not abide the essential rules of the game for this type of exercise. I'm more of a thinker, and I'm usually simply amazed and left without response for the first minute when for example someone says something rude on a personal level "if you're so smart, why can't you think of the answers yourself ?", or is negative without providing alternatives such as "we've already tried this 5 times and it doesn't work". Both of these examples actually happened to me on other occasions.

Personal relationships help me prevent people breaking the rules and help me respond correctly when people do break the rules nevertheless. Some managers or architects can enter a situation with personal relationships that have grown hostile over the years without prior knowledge of this, do this exercise within the first two weeks, release almost all of the tension, and cause very little personal damnage. I've seen some of them do it, but I'm not one of them. Maybe one needs to know his own limits as an architect or as a manager before embarking on this kind of dangerous boat trip over rough and unpredictable seas.

Nevertheless, although it takes much energy diverted from other tasks, I felt it was worth it. I'm surrounded by some very technically focused and results driven people in the department who may beg to differ on this, but the teacher of the lean-six-sigma course I'm following framed it like this:

• Result = Quality (of the work) x Acceptance (by the stakeholders)
• Effort spent on acceptance + Effort spent on quality work = A limited constant

The lesson being: If you spend all your time working towards results, the result will be zero. If you spend all your time on acceptance, the result will be zero as well. Hence, there is an optimal balance, which depends on how much acceptance and quality you can get for your effort. Spending one third on communication may seem like a lot, but actually may be close to optimal as well.
I've seen this in other simpler formulations as well, but here's what seems essential to me. And things should be made as simple as possible, but not simpler. Who thought of that, again ?

Just one of those days

Today I was quite tired from spending two days in HQ Zürich on international application access and the user provisioning, authentication and authorization to go with it. Before flying home yesterday evening, I took the time to buy a few presents for my wife and kids.

At ten o'clock, I went into a meeting to help define a process that is needed for the e-business project. There were quite a few issues, and some of them I didn't even know about. We tried to solve them all at once, and when the first was halfway solved, somebody came up with a new one and everyone felt like they needed to respond or to help out, and we were all trying to get attention for ourselves. This didn't work, needless to say. For the first time in my life, as far as I remember, I got so fed up of not being able to add any value, that I literally walked out of the meeting, until the same gentle person as in my previous post, actually came to get me and we all took a break. This was brilliant psychology, and we actually did solve a few issues after the break. Not all of them, but we made a hopeful progress.

As a result, I missed a lunch appointment with a former colleague. In the afternoon I could do some useful stuff for the lean six sigma project that our team of 3 is doing for education and real life at the same time, help out one of the colleagues on UML tools, help out my CTO on end user computing etc.

At 17:10 I attended the steering of the e-business project, and hoora, even more issues I wasn't aware of popped up that needed to be discussed.
At 17:50, while the meeting was still going on, I told everybody goodbye. The agenda point that I especially came for wasn't treated (as an architect, I don't attend all project steerings, this was a special occasion).
In the hope of getting home by 19:00, as I promised my wife who took care of the kids while I was in Zürich.

But the ordeal wasn't over yet. The train was delayed by 15 minutes, so I missed my connection in Leuven, and the next train out of Leuven home was late by 8 minutes. Total delay: 55 minutes.

The architecture lesson here is that in discrete processes, the end-to-end service level is not some kind of linear sum of individual service levels. Although each train was only slightly late, the end result was rather seriously late because of the missed connection. How am I going to make up for this to my wife ? Any suggestions welcomed.

Taking the trouble to communicate

This morning, a colleague, who I've not known for so long, because I recently accepted another work challenge, called a meeting. I'ld describe him as eager to move the company forward, competent, experienced, gentle and kind.

The meeting was on an e-business portal project he used to be a project manager of, and whose role has now been taken over by someone else. Voluntarily, I might add, as he saw his value to the company would be greater in his new role. Anyway, since I work there, we've had together:

• one informal meeting on the project,
• one workshop on portal user administration, answering portal user questions and publishing processes with all of the management of teams concerned, and
• two formal meetings with the management, specifically to organize and decide on answering portal user questions.

All except the first meeting were properly prepared and reported. Nevertheless, in this mornings meeting, I noticed some communication problems. We were not aligned on how to position the portal in the company, and on the meaning of the decisions made earlier. While I could understand his arguments, I was very surprised not to learn about them earlier. Somewhere along the way, I'ld lost him in the communication process, probably too busy.

How could that be ? Still trying to figure out ...

Not a problem anytime soon, but as an architect I tend to think on a 2 to 3 year time horizon. I must re-establish communication and align ourselves within the next few months.

Intentions and red tape

Why blog ? Will I actually write something worth reading on here ?

The truth is I don't know yet. And up for you to judge, so your comments welcome. Don't hold back, I can take a punch or two.

I intend to use this blog for writing about enterprise architecture, IT governance, process and quality from a practical viewpoint. With the same intent, I'll add a personal touch now and then from the everyday experiences I come across.

Now I'm off to corporate communications to get the red tape that'll be needed.