Does it ever seem that as an Enterprise Architect, we have many dragons to slay? Our organizations confuse the Chief Architect with chief technology problem solver, and it isn’t their fault. Often the current technology hot spot of the day is something that lives in the EA realm, and we are the captain of the ship.

We’ve had many metaphors – the Builder, the Architect of a house, the City Planner, or perhaps the Pilot of an airplane or ship (thanks Mr. Zachman!). Here is mine:

An organization, when embarking on an EA program, needs a cook. They need to mix some things up to create a tantalizing dish. There is not often one recipe, but several that might suit the ingredients you have at hand. At some point, depending on the size of the organization, you may find that there are too many cooks in the kitchen, and a chef de maison, or Head Chef is required. The chef will prepare the menu, and ensure that the restaurant has the ingredients at hand.

What the cooks do to add flavor and seasoning may be their choice, or it may be strictly regulated. The McDonalds restaurant does much to ensure that their food tastes the same each and every time. Some restaurants to do – these are not chains, but individual “spots” for a bite out.

Sometimes, there are too many cooks in the kitchen. As of late, I’ve seen several folks try their hand at mixing and matching SDLC’s. The chief architect may or not get involved from a standards perspective, or from a governance and compliance issue with respect to artifacts. There is no “right” SDLC. The facts are simple – too many cooks will ruin the soup – too many flavors will confuse the issue.

One recipe may be selected for the best “dish of the house”. There is room to decide whether the head chef is creating the meal depending on the appetite. If there is appetite for chateau briande, so be it. The SDLC will be complex with many options. If there is only appetite for deli or fast food, or perhaps even the corner restaurant that sells burgers and fries, the SDLC must be simple with few key artifacts and simple methods.

Chefs – the choice is yours. Remember, if there are too many cooks in the kitchen, there will be a fire!

Happy Architecting.

Well – it’s been far too long since I wrote – but I am committed to writing more. I’ve just been exposed to “governance Overload”. What is it you say?

Well – after a weekend in Boston and time with the ultimate of buzz word abusers (this generic professional group shall remain nameless), I’m sick of “get it done”, “dropping the ball”, etc. etc.

Instead – I come home to a day on my new gig and abuse of the word governance. This blog has turned into a bit of a rant against the abusers of IT architecture and now it’s time to spout off against those who can’t find their way into a wikopedia entry.

Architecture Governance is different that IT Governance. IT Governance is NOT, and I repeat NOT project prioritization. It might include it, but it is not it. IT Governance includes the process around IT decision making, adhering to standards, patterns and process guidelines. Architecture Governance is the process around governing adhering to Architecture frameworks, guidelines, principles and standards and the methods to make your way around them.

Why does this matter? Confusion about terms such as governance is rampant and since people like to exchange the word “architecture” for the term “diagram”, it deserves more references here. Governance is about the process of systematically and orderly controlling the process around decisions. In this case architecture or IT governance. In my case, Architecture governance allows those who wish to sway from the norm to get a say and have a chance at doing something that is right, but isn’t necessarily status quo.

Today I sat through a meeting requiring an architectural decision. For a change, I am in a position of both authority and influence and got to be the governing panel. I listened to those who wanted to argue their case for option B when option A was status quo. After all was said and done I couldn’t choose either. Both were silly and didn’t make security, architecture, nor financial sense. It was option C that won out. See – what a great example of how architecture reviews make sense and are worth the effort. No one came expecting option C to be chosen even though they were afraid to choose it.

Option A was status quo and everyone geared up for option B. By bringing it to my attention, raising it to the top of my radar screen, option C was up for consideration and it won. See – there is a point. There is democratic decision and discussion. Architecture review boards, their process and methods are worth the time and efforts attributed to them.

that’s my thoughts for tonight – hopefully I’ll be able to share more another day – this was fun!

Sharon

I’m sure as many of you do, you reach home after a weary four days of work and are frustrated because your work seems to be one big giant conflict. You spend an hour and a half of a one hour meeting (notice that we only went over by 50%?) going back and forth and back and forth. You might get a turn with the magic white board markers, confident that once you play picasso, everyone will get it and the argument will be over.

Well – was I in a doozy today – I just sat and played the referee, as it was the role I was paid to play as Chief Architect of an Enterprise Architecture program – I would ask questions like “What if you were to …” and see what they’d say. At the end of the day, I took on another role – it was to say – something like “let’s say there are two options – which would you prefer?”

Now we’re getting somewhere – people are always better at pointing out fault with something concrete, rather than trying to come up with pieces of something or arguing about minute points.

If you get to play architect, this might be one tactful approach. Architecture is more about politics than it seems to be about technology. You can’t just show up as a great IT polician and expect to be a good architect, but if you are a good architect, being tactful and a great politician sure helps.

So back to the dilemma at hand. Do you ever notice that at the end of one of these types of meetings you are down to two options? It’s not that there are just two choices, but there are two that the group hasn’t discarded and are willing to back. Pick one, see if it looks like swiss cheese, and then jump ship if it seems that it won’t float your boat!