Enterprise Architecture: How many meetings do you attend in a day...

Scheduling meetings for a late project makes it later...



Let's go around the table. Hi, I am James McGovern and I am standing in for pointy haired boss of the impediment solutions division. Who else is on the call?

Seriously, You have a problem with schedule. To solve this problem, you start making meetings. People that should be involved with delivering the project start to be involved in this meetings. Project gets later, oh... Yet another meeting will solve it.

A wise executive I know scolds his employees for showing up late to meetings and makes mental notes as to how much wasted time occurs. Imagine if we could equip all the conference rooms in your building with ID badge readers, and big NBA scoreboard-type displays. All meeting participants are required to badge in on their way in the door. The software looks up their salary or contract rates, and provides a minute-by-minute updated view of the cost of the meeting. Unfortunately, this would only capture the direct costs, and not reflect the other inefficiencies related to attending the meeting.

Not all meetings are bad. There is also a tremendous amount of effort wasted when people do not have meetings to ask for clarification, alternatives, or help. When a project is behind, one of the most productive things to do is to get representatives of the development team and the end users together to decide how best to proceed given where we are at today. Likewise, imagine if someone ever figured out the cost of all these meetings where the vast majority of folks who attend aren't prepared to attend.

One meeting tactic that I have been known to encourage those who are behind is to ask themselves whether they would be the stupidest person in the room. If the answer is no, then you probably don't need to make much effort preparing as most meetings slow down to the lowest common denominator.

I wonder how many folks are reading my blog while in a meeting from their Blackberries? I wonder how many meetings I have held up where folks where waiting for me and otherwise wasted a lot of time until I made my grand entrance...

Enterprise Architecture: Why does modern EA feel more like a holy war?

Have you noticed that the conversation nowadays is less about principles and more about perception? How can IT ever align with the business under this mantra...



Here are several reasons why IT feels more like a holy war where EA is at the center of a jihad...

• Perception of Change: People simply perceive change and patterns of change differently. Changes that may have burned some designs may not have burned others; or perhaps if somebody gets chewed out for the inability to handle change A, but not for the inability to handle change B, then in the future they may focus more on reducing A-related change problems at the expense of B.


• Standards versus Freedom: Some people seem to like standards because they either provide ready-made solutions, or reduce the variety of solutions offered by others, making reading other's code and debugging easier. However, sometimes it is nice to model things after one's own mind for a more comfortable fit, regardless of how standards suggest doing it.


• Presentation Absorption: Different people absorb information quicker in different forms. A presentation approach that is easy for person A may not be easy for person B, and vice versa.


• Different Values or Objectives: For example, to make something secure because compliance says so regardless of how painful it may be for end-users vs not caring at all about security and only having a thought about usability.

Is Enterprise Architecture forever doomed to mediocrity...

In any large organization, perception is more important than reality. If an Architect is not good at creating the perception of value by doing architecture, this effort always fails...



In a reactive environment, it is nearly impossible to create value for using architecture. Architecture in a typical company is always doomed to fail. Of course, we can put a spin on everything and publish our success when reality says that we will never achieve more than mediocrity if measured through the lens of perception.

Has anyone else noticed that sometimes you never get anywhere by saying that this will make the product/project/etc better? Nobody gives a frig. Maybe we are mediocre because we haven't yet figured out how to attach it as a rider to a business requirement? Architecture is not easily measurable or quantifiable in numbers. You can not really attach a dollar figure to architecture benefits.

One should always ask both sides of the debate. One question is how to manage a defacto architecture while another is to ask did we ever have an architecture in the first place? We don't seem to have a consensus as to what the word "Architecture" means. Maybe that's because it was a word invented to fit an organizational structure.

• Archi: To rule


• Tectum: Roof

So architectum is to rule the roofs. An architect is the ruler of all the roofs, meaning the person who decides how the roofs should be like in the city, so that the city has a unifying vision.

Actually, the word comes from Greek archi-==chief- + tektwn==craftsman, i.e., chief-craftsman. So let's agree that if we rule the roof's, our heads are somewhere in the clouds. Likewise, how can you consider yourself a craftsman if the vast majority of people within IT don't even understand the basics regarding crafting IT ecosystems?

Interestingly enough, about a century or two centuries ago, architects were the inventors of buildings, they put their names on them. Nowadays, most architects don't even want to be associated with things they have created...