Standards: a good thing when they're good standards ?

You probably have witnessed the corporate dynamics around introducing standards already. It's a typical architecture instrument. Here's the basic forces in the forcefield:
- Standards are good for cost control and clarity. Most CxO's approve, support and enforce them.
- Enforced standards limit team level freedom and therefore narrow the solution space to a given project challenge. Sometimes this is good since it forces people to see the big picture instead of this years' personal objectives when designing a solution. In this case, the solution space is not really much narrower, since a perfectly fine solution to the project challenge remains available that also meets the big picture constraints (despite all the whining about .NET being more productive and fun than Java EE). However there are cases in which the solution space is severely narrowed, which forces the team to either play the game and try to get away with non-standard, or solving the given project challenge badly. Since noone, and especially an architect, likes spending his life delivering bad solutions, most teams will play the game.

This is where this story gets interesting for enterprise architects. This will turn out to be a personal attitude thing again, but the important point is this: enterprise architects need the ability to recognize business innovation that requires non-standard technology.

A lot of professionals get by on meeting reflexes as a substitute for thinking. These guys are lost on my point above: whenever someone suggest to use something non-standard, they will retaliate and a loose-loose power struggle to enforce the standard vs. solve the project challenge is on. Innovation is often seen as a weird idea at first. This was true for, chronologically, hot air balloons, steam trains, airplanes denser than air, cheap hotels low on staff, B2B fully automated services, and boeings flying into buildings (probably a lot of Jihadis would have found this weird too, I wasn't there when Osama proposed it at first, but thanks to Jens for making me see this was actually terroristic innovation - after this post we will both be on Echelons black list and get the rubber glove treatment on our next entry into the US :-)). None of this would have happened if these organisations or individuals would have respected their standards.

Now, what does it take to be enterprise architect material and recognize business innovation when you see it:
- How does the projects business challenge differ from the generic process that standards were based on. This requires a view on what makes a business case, what is business innovation, what the standard technology can reasonably support, why this technology was chosen as a standard etc.
- But most importantly: an open mind for weird ideas. Listening, using your knowledge to think and judge efficiently, taking a commitment to solving the project challenge together, and the persuasion power to either enforce the standard when it doesn't narrow the solution space, or to convince CxO's to let go of standards for really intrapreneuring projects.

I've had quite a few windmill fights over these issues in the past 13 years. Not a very abundant skill in corporations ?

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.