We didn't start the fire, so when do the hoses arrive?

The meeting has begun.  It is a meeting I have been dreading for three weeks.  Odd, really, when you consider the fact that I'm the meeting organizer and it's been darn next to impossible to get it to happen.

"Let's hear your idea," Franz starts.  Franz is a leader of a self-sufficient IT group assigned to one of the 'businesses' within the bowels of the company.  He is flanked on his left by his 'Chief of Staff,' a new position that is springing up around mid-level IT executives, the Chief of Staff is essentially an uber-project manager assigned to their pet projects to provide visibility (and control).  The chief of Franz' staff is a thin fellow named Jay, mid fourties, just as tough as Franz.  On his right is Mary, the leader of his Project Management team.  He came prepared to listen... or shoot me down.

"I'm here to talk about a new structure for empowering the Architecture team to perform their Governance role."  I wonder how long he will let me swing.

Franz and I have an interesting relationship.  Franz in a tall man in his late fifties with bushy, almost wild hair.  He speaks with a soft German accent, even after so many years in the US, and carries himself with confidence.  Franz has the air of someone who knows he is right.  Usually, he is.

I launch into my presentation.  I've given it about a dozen times already, to nearly every other executive at his level, trying to get traction.  His boss has taken an extended leave of absence, and I need buy-in from his level.  Moving up the ladder is not useful to get my idea to fruition.  I'm left with the need to convince each member of an extended team about Architectural Governance, and it's not easy.

I ramble on about artifacts and interaction models.  I describe responsibility assignments and escalation paths.

Slowly Franz starts to pick up interest.  He asks questions, good ones. Then comes the first shot across the bow.

"If my business comes to me with an urgent project need, and I analyze the project and tell them it will take 4 Million to do it, in needs to take 4 Million to do it.  I can't come back and say that it would have taken 4 Million, but the architects want to slow it down, tie it to six other initiatives, and raise the cost to six!" Franz finishes with a flourish.  He has placed the Truth As Franz Sees It on the table and dared me to pick it up.  I have to think quick.

Franz is excellent at getting the right people to agree with him.  He has a saavy way of handling situations... not so much in the moment, but rather by careful manipulation.  He never looks like he is dragging his feet or delaying things on purpose, even when that is precisely what he is doing.  When he does push an idea, it doesn't look so much like promotion as 'an absense of resistence,' while someone from his staff proposes the idea and takes the risks if someone higher up doesn't like it.

Screw up with Franz and the idea is dead.

"I completely agree."  I start.  "If the business comes to you with an urgent need, you have to be ready to help.  And that is what governance is all about.  It lets you be ready, so that you can respond quickly, not to this week's hair-on-fire episode, or next week's, but next months crisis is reduced and next year's crisis is avoided."

It was a valliant effort, but I could tell from the look on his face that he wasn't buying it.

"Look, my team is always buffeted by demands."  Mary jumped in.  "The business will pick at our estimates, trying to take them apart, questioning everything.  They negotiate every ounce of 'fat' out of every project.  There isn't any room for building things that we can't prove that they need right now."

Franz turned back to me.  Mary was Right.

"There is a way around it.  You have to hit them with a vision, sell them on it.  A vision of how their systems will behave to their benefit."  I had to emphasize the last three words.  "We can build a simpler architecture that allows their business to leverage the tools we have, the expertise we have, to allow for 'Rapid Successes' that are both rapid and successful."  My turf now.

"Agility," I continue, "is not just about how you write software.  Agility is also about the software you choose to write!"  I pause for a moment, to allow that notion to sink in before continuing.

"If a system is architected well to begin with, with loosely coupled systems communicating rapidly over a scalable EAI infrastructure, then business change can be empowered much more quickly.  You are changing small, simple, easy to test components, instead of large legacy applications."

He knew all this.  It's the standard SOA speech.  He's heard it before.  He probably gave it, once.  Problem is, it assumes a world he doesn't live it.

"Jay," I ask, turning to his Chief of Staff, "tell me.  In the past year, how many projects came in with the stamp of urgency, bad requirements, and no time to get it right before developers were writing code." 

That one caught him off guard.  "Um, I'm not sure what you mean."  Good answer. 

"If a project comes in, and the business wants a particular functional change, how much time is spent analyzing the problem?  How much care is taken before everyone signs off and you start changing code?" I reply.  I'm on thin ice.  It's a desperate move.  I shouldn't ask the question if I don't know the answer.  I'm gambling in his need to always 'look good' for Franz.  That's why I picked my words as carefully as I could, considering the fact that I'm desperate.

"We take as much care as we can, but we can't always predict things.  Like last quarter, when the business came in with a program to change the way we recalculate prices for one segment of the market based on a totally different volume mechanism.  That one meant changes in four mission-critical systems, but they wanted the changes 'yesterday.'  That was a nightmare."  Jay darn-near put his head in his hands. 

"Right.  Now, there's been smart people in your group for years.  Why was the code to calcuate the price by volume buried deeply in four different systems?  Why wasn't it focused on a single system?  Is that smart?"  I replied.

"No.  It's not smart, " retorted Jay, right on cue, "but those systems had grown up over time, independently of one another.  We knew that there was some overlap, but the business never wanted to pay to clean the mess up." 

"And that," I said, turning back to Franz, "is why you need Architectural Governance.  You are here now, and will be here for a long time, but you don't have to be here forever.  You can break this cycle by investing in Architecture now."

I continued, "Get a group of your smartest people to create the rules that No One Breaks, sell your business on the notion of living by the rules, and empower the team to strictly enforce them.  No exceptions.  If the business has their hair on fire, give them two alternatives: spend less and take time to do it right, or spend more and do it twice.  The short term fix has to end, or you will never get out."

"That is how you prevent these things.  That is how you invest in system flexibility.  That is how you pay off 'developer's debt.'  Over time, the fires are not as hot.  If agile development methods are about how you build systems, Architecture is about what systems you choose to build."

By the time the meeting broke up, I think we had a common understanding of what I am trying to do.  Only time will tell.  One thing I did learn: I never want to play Poker with Franz.