Wonder whether this ever happened to you ?
We're a bit overorganized around here. We have a 3-dimensional matrix management structure, in which each staff member potentially reports to the well-known line management dimension, project management dimension and additionally to what is being called "functional management". It actually means you report to someone who defines standards and practices for your "function", in my case as enterprise architect.
Today I have actually become the project manager of my own functional manager, and also of his functional manager. That kind of proves my first point about being overorganized. This is due to a chain of 3 organizational decisions: the first was a decision by the architecture board that an architecture task, on which my functional manager and his functional manager were both working, is to be completed by a certain business programme, the second a decision of the programme management to delegate the task to the IT project in the programme, the third a decision of the IT project management to delegate to the enterprise architect on the project, which is me. That closed the loop.
I'm still considering whether I will cut my functional managers' project budget tomorrow or just make them work overtime :-) .
Wednesday, January 21, 2009
Wednesday, June 11, 2008
IT en voetbal
Een typische voetbalavond vandaag. Om 15:00 een vergadering met een collega, die het plunje van zijn "Nati" draagt. En selbstverständlich niet anders dan in de hoogstnodige Sieg gelooft. We wensen elkaar geluk. Om 20:30 een spannende wedstrijd, waarin "wij" eerst 1-0 voorkomen, daarna nog twee tegengoals moeten incasseren. U merkt dat ik me al een beetje thuisvoel. Wat een droefheid. Morgen voorzichtig de sfeer aftasten. Voetbal en IT, één en al emotie.
Tuesday, May 27, 2008
Ein Architekt in der Schweiz
OK, I'm off to Switzerland to do an extremely interesting project - which is of course, as we know the Swiss, ultimately confidential and therefore you will not read much about it.
If someone knows an address where I can buy a copy of "Asterix chez les Helvètes", I hold myself recommended. Still need to buy my half-fare card as well.
Just a few general opinions on the cultural differences I have noticed till now. Most of the clichés on the country appear to have some truth to them. In quite a few business letters I received till now (mostly to arrange a few private affairs), I am treatened with all kinds of consequences in the second last sentence if I do not comply with procedures within a defined period. As in "if you drop your piece of bread in the fondue for the third time, you will be thrown into the lake". Not that any of these consequences would be less grave in Belgium, but we usually do not feel the need to mention them explicitly on the first business letter.
I am very impressed by the efficiency of business processes (which seem to be well thought through in advance of operating them) and the high quality of service I generally receive, for example the service I get from my Swiss bank. Swiss banks truly operate in another league in that field. I don't see a lot of difference in the front-office, in both countries front-office staff will do whatever is in their power to help their customers, but at my Swiss bank, the back-office seems to be much better aligned. And even construction workers have delivered on the promised date (twice already). Flexibility in responding to unanticipated customer requests is a bit less, though.
The way politics are close to life has impressed me as well. Although I obviously have no right to vote, I receive about 10 times as much leaflets from political parties and initiative committees as I do in Belgium, where only the extreme right party goes through the trouble of writing and posting leaflets instead of limiting themselves to group-chats in their local café. These leaflets explain the stakes really well if you combine the for and against arguments from different parties. The direct democracy seems able to make though decisions, reinforces the sense of community and if you gather enough signatures within a defined time period, any group of people can launch their own political initiative. The opposition parties have a more active role than just decrying shame on the coalition in force. Subsidiarity between gemeinde, cantons and bund is a frequent topic of debate, though. Seems like a nice idea for my country as well, as it forces politicians to explain their voting recommendation clearly to the public instead of cooking up ugly compromises among themselves in some secluded chateau. For which they know they won't be punished until the next election, when everyone has forgotten the stakes and the stands. I learned that the local Jean Marie DD is called Christoph Blocher.
More impressions will follow as I go. I hope I will keep noticing the differences.
If someone knows an address where I can buy a copy of "Asterix chez les Helvètes", I hold myself recommended. Still need to buy my half-fare card as well.
Just a few general opinions on the cultural differences I have noticed till now. Most of the clichés on the country appear to have some truth to them. In quite a few business letters I received till now (mostly to arrange a few private affairs), I am treatened with all kinds of consequences in the second last sentence if I do not comply with procedures within a defined period. As in "if you drop your piece of bread in the fondue for the third time, you will be thrown into the lake". Not that any of these consequences would be less grave in Belgium, but we usually do not feel the need to mention them explicitly on the first business letter.
I am very impressed by the efficiency of business processes (which seem to be well thought through in advance of operating them) and the high quality of service I generally receive, for example the service I get from my Swiss bank. Swiss banks truly operate in another league in that field. I don't see a lot of difference in the front-office, in both countries front-office staff will do whatever is in their power to help their customers, but at my Swiss bank, the back-office seems to be much better aligned. And even construction workers have delivered on the promised date (twice already). Flexibility in responding to unanticipated customer requests is a bit less, though.
The way politics are close to life has impressed me as well. Although I obviously have no right to vote, I receive about 10 times as much leaflets from political parties and initiative committees as I do in Belgium, where only the extreme right party goes through the trouble of writing and posting leaflets instead of limiting themselves to group-chats in their local café. These leaflets explain the stakes really well if you combine the for and against arguments from different parties. The direct democracy seems able to make though decisions, reinforces the sense of community and if you gather enough signatures within a defined time period, any group of people can launch their own political initiative. The opposition parties have a more active role than just decrying shame on the coalition in force. Subsidiarity between gemeinde, cantons and bund is a frequent topic of debate, though. Seems like a nice idea for my country as well, as it forces politicians to explain their voting recommendation clearly to the public instead of cooking up ugly compromises among themselves in some secluded chateau. For which they know they won't be punished until the next election, when everyone has forgotten the stakes and the stands. I learned that the local Jean Marie DD is called Christoph Blocher.
More impressions will follow as I go. I hope I will keep noticing the differences.
Monday, May 19, 2008
Evolutionary and Structured
One enduring problem of architects, and enterprise architects in particular, is we tend to perceive our enterprise (cfr. TOGAF for a definition) as something we can/must structure to optimize it. Using an enterprise architecture framework, for example.
Time to look around: most of the things you will see around you have been improved by evolution, i.e. successive generations of selection, recombination and mutation. Seriously, look around. This blogging application. Your workstation. The chair you are sitting on. Your keyboard evolved from the typewriter. Also, there were many lesser designs on the way.
Which designs survive, is sometimes determined by great ideas, sometimes by pure coincidence. A bit of marketing may help, also.
Lately, I tend to take the view that filling up an enterprise framework can be done really, really shallow, then select a few (max. 3) focus areas for being inspired by evolution. It is enough to find a few champions, coordinate their work just enough, realize a few designs that you can breed with. Changing surroundings may do the rest, and weed out some competing organisms. If you pick the right genes to start with, of course.
What is really shallow ? 2 levels of business process, 2 levels of roles, without sequencing and only the most important business documents = a business architecture. An application list with a few features and interfaces for each application = an application architecture. A technical components list and a preferred technology list = a technical architecture. A list of infrastructure platforms and databases = an infrastructure architecture. You can't do a thorough impact analysis on that, or present an architectural business case with several solution scenarios, but it may be enough to build a common understanding and get evolution going. Then, structure only the parts where this brings a real advantage to the development process itself.
How come ? It's important to be understood by most colleagues. It's not important to have everything documented. It's important to be fast. It's important to have essential things documented. It's not important to be rigidly structured (forget large-scale reuse first). It's important to adapt to what happens around you. As an enterprise and as an architect within it. Especially if it's chaotic. It's important to tell a story. Of just a few essential projects that worked. It's important to have essential team discipline. It's important to open freedom of imagination. It's important to feed ownership. It's important to have just enough common reference to communicate.
Keeping the right balance depends on the wind strength, but also on its variability.
Time to look around: most of the things you will see around you have been improved by evolution, i.e. successive generations of selection, recombination and mutation. Seriously, look around. This blogging application. Your workstation. The chair you are sitting on. Your keyboard evolved from the typewriter. Also, there were many lesser designs on the way.
Which designs survive, is sometimes determined by great ideas, sometimes by pure coincidence. A bit of marketing may help, also.
Lately, I tend to take the view that filling up an enterprise framework can be done really, really shallow, then select a few (max. 3) focus areas for being inspired by evolution. It is enough to find a few champions, coordinate their work just enough, realize a few designs that you can breed with. Changing surroundings may do the rest, and weed out some competing organisms. If you pick the right genes to start with, of course.
What is really shallow ? 2 levels of business process, 2 levels of roles, without sequencing and only the most important business documents = a business architecture. An application list with a few features and interfaces for each application = an application architecture. A technical components list and a preferred technology list = a technical architecture. A list of infrastructure platforms and databases = an infrastructure architecture. You can't do a thorough impact analysis on that, or present an architectural business case with several solution scenarios, but it may be enough to build a common understanding and get evolution going. Then, structure only the parts where this brings a real advantage to the development process itself.
How come ? It's important to be understood by most colleagues. It's not important to have everything documented. It's important to be fast. It's important to have essential things documented. It's not important to be rigidly structured (forget large-scale reuse first). It's important to adapt to what happens around you. As an enterprise and as an architect within it. Especially if it's chaotic. It's important to tell a story. Of just a few essential projects that worked. It's important to have essential team discipline. It's important to open freedom of imagination. It's important to feed ownership. It's important to have just enough common reference to communicate.
Keeping the right balance depends on the wind strength, but also on its variability.
Tuesday, October 2, 2007
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 ?
- 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 ?
Wednesday, June 13, 2007
The war is on
Two facts combined in my mind yesterday:
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:
- 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).
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.
Tuesday, June 12, 2007
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:
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:
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 ?
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.
- 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.
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
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 ?
Subscribe to:
Comments (Atom)