interesting word (help keep it alive on wikipedia) http://en.wikipedia.org/wiki/Ilackasourceism
This word is all about the relavence and value of an assigned reference. If you use something as a reference point that isn’t valid – you suffer from this horrible problem.
Wikipedia has already started the process of removing this word, as it should the word means nothing other than simply stating, validate your source!
Personally I call them luminaries. It comes from the concept of shedding light which is what I expect a visionary to do. Open a door or shine light on a concept or process that previouslyhad b ad been “dark.”
So who are the “luminaries” in the architect sky? Who lights the way and shows things we didn’t see before?
1. Paul Priess of IASA. He is driving towards the creation of an architect profession and is lighting the way for thousands to follow.
2. Dana Bredemeyer (and Ruth who are taking the concept of visual architecture and making it into a standard.
3. Miha Kralj who actually tried to create the profession architect within the Microsoft partner, services and MVP communities.
4. Alan Hakimi the only person I know who is “being” an enterprise architect at Microsoft.
5. Jim Wilt – one of my personal heroes!
6. Ryan Plant, Richard Webb, Andy Ruth, Delbert Murphy all excellent examples of what an architect could and should be…
Who else? In the last six months I’ve personally been invovled with a lot more architects then I had previously. I find that most architects today are confused about the potential of our profession.
So who are the luminaries today? Who are the people that will help us become a profession rather than a job title.
.Doc
There used to be a game (only 7 relationships away from Kevin Bacon or 7 degress). But within the growing profession architecture, what are the degress that separate us?
Well today we are not a profession. Building architects are a profession we are a group of professionals in a professional role but as software architects we are still not considered a profession.
Many will take umbrage with this, but the reality is true. To be a profession you have to have a single governing body for people to disagree with. Today we are close (IASA) but we are not there yet.
So what separates us from a profession?
1. Definition – we are still unclear as to roles vs actions with the concept of software architecture. We are all software architects but then we have roles (Enterprise Architect, Infrastructure Architect, Solutiosn Architect)beyond the three Information Architects, business architects all clamor to be considered. We also have roles with architects, selling vs delivery, product specialzed , solution specialized there are as many variances as there are architects.
2. Many definitions, sadly you put 15 software architects into a room, you’ll come out with 16 different definitions of software architecture. When we get to 1 or 2, then we are a profession.
3. Badge of honor, perhaps the last and most difficult, when your profession exceeds your own status. I am a software architect. When you can say that in a room full of Doctors and Lawyers, school teachers and accountants, then we are a profession.
It isn’t much, anymore that separates us from a profession.
.Doc
The concept of the Architect Toolbelt is something that Richard came up during an MCA board. That toolbelt that contains the “things” an archtiect needs.
I’ve thought about that for a long time and have finally decided what I think should be on the toolbelt:
1. documentation related to the architecture the architect is responsible for.
2. Patterns and Practices related to the development of that architecture.
3. Vendors and partner’s that deliver components of the architecture.
4. The requirements of the solution documented in a formal requirements document.
5. A business mapping – what business problem is this solution solving?
6. A traceabilty matrix for the requirements mapping into the architecture and then beyond into the deployed solution.
I don’t think this toolbelt would weigh you down that much :-0 But i would like to see people leveraging these types of tools going forward.
.Doc
Why do people stay for a meeting in a room too small?
My communication question of the day, how is it that you go to a meeting in a room that is obviously way to small – and you stay. Perched perhaps on a cabinet or sitting on the floor, to be engaged and invovled in this, over crowded meeting.
While next door an equally important meeting is going on, in a room that is way to large with people leaving.
Does the size of the room impact the importance of a meeting?
I used to work in a product group of a company. VP’s always got the big rooms for their meetings. Even if it was a tiny meeting about a tool that impacted only one group, every meeting was full. Everyone had to tout their importance and show the VP how much they knew.
In the end nothing much was accomplished. In reality this was because people spent their time jockeying for position with the Vp, but I digress.
Does the size of the room impact the attendance of a meeting? Or is it more the quality of the person running the meeting and not the room at all?
My vote is that in fact it is the quality of the person running the meeting is the most important thing. But, the reality of the world is that the value of the person running the meeting may be high to the meeting, but low to the organization so they end up with the smaller room.
Communication, space and the other components of meetings determine the success of our work day and the success of our work lives.
So, as I’ve talked about all week. The most important part of leadership is listening. Great leaders listen first. They don’t homage to the concept of listening they actually listen. They report to you what you’ve said in their words.
The small room doesn’t impact the size of the meeting. The listening ability of the meeting organizer is what drives attendance.
Toodles – it’s the weekend!
.Doc (version two of /doc)
I was part of a global rollout of a solution 12 years ago. At the time of the rollout we were doing new technologies and replacing old technologies and things weren’t flowing as smoothly as they could have.
In a meeting one of the team members from Boston used the famous quote “communicate, communicate, communicate” when asked how we could get the project back on track.
That is one method for getting a project off the rocks.
What others work? I know that I’ve worked with various PjM’s over the years. They believe (and rightly so) that the overall approach of a plan driven solutoin will keep the solution on track.
That is another approach – doesn’t work as well if the proejct starts off, off. But if you start with a plan you do quickly see when you are in fact, off.
Its too bad there isn’t a GPS for projects .
It all comes down to the concept that I heard once in a Microsoft Solutions Framework class, no project ever got 6 months off track, in one day. If, the project got off track by 6 months, it happened over the course of the project. Which comes back to the concept of communications.
If the communications structure in a project doesn’t work, the project will eventually fail. It’s a two way street (communications) and there are a number of characters that will impact that communication.
I talked about the pirate, people who don’t listen, dancing bears and a variety of communication patterns that cause projects to have issues. There is also the hoarder, a person who doesn’t communicate with anyone else, excpet for what the hoarder believes that person needs to know.
Seems to me, the advice I got years ago still stands. “Communicate, Communicate, Communicate”.
Just remember that communication, is a two WAY street.
TGIF
/Doc
Cheese.
A good meeting looks like swiss cheese mixed with cheddar and melted togheter to form a creation that looks something like cojack.
If only good meetings were that easy to identify. A good meeting means that people find value in what was presented, no one felt like it wasted their time and the solution moves forward at the end.
How often do we sit in bad meetings?
Over the years I’ve compared some meetings to dancing bears with colored markers. People standing in front of a group of people that don’t listen.
So skill one – listen.
I’ve also sat through meetings where one or another person (see my pirate blog) hijacks the meeting.
Skill two – have a good agenda that accounts for all people invovled.
Finally I’ve been in meetings where the leader didn’t really know where the meeting needed to go – a lack of vision
So skill three – have a vision for each meeting.
Now all of these points are rather common sense. Yet I’ve seen people who’ve led meetings for years – that fail on all three of these points in the same meeting. The dancing bears with colored pens is frustrating as a participant because they don’t hear anything you say. I was in a meeting once a lont time ago, where a dear friend pulled me aside and said “I had something to say about 1/2 through the meeting and waiting the entire rest of the meeting for the two bears to stop arguing. I never got a chance to make my point.”
Problem 1 – I didn’t get a chance to make a point.
Problem 2 – organization
Problem 3 – vision
Problem 4 – good old boys club.
Perhaps my vision and scope for meetings is all wrong. I run into the four problems above and the three missing skills in virtually 1/2 the meetings I attend. The end state is I often walk out of these meetings feeling like I wasted however much time the meeting was, by being there.
Maybe it’s time to write a book, communication in the new age.
/Doc
find me on the web:
Fred and Ed Podcast http://docandersen.podbean.com/
My other blog: http://docandersen.spaces.live.com
I’ve been an architect for a long time. I’ve seen flavors come and go (SOA, Windows DNA).
I’ve joined the architect flavor of the month club a number of times.
But I have come to realize that many of puzzles that my customer’s fear and continue to address are actually something that myself and my fellow architects have created.
Truly this isn’t fair in the sense that in most cases the architct is driven by the business requirements they gather (and the requirements they act/live under). So it’s not completely our fault.
The issue is many fold – first is the job market. They say the average CIO is in that position for less than 3 years. LIke a president – in four years you cannot affect or effect large scale change. So CIO’s don’t conduct large scale change projects. This creates an architecture of holes, fill in the current largest gap – leave the rest of the gaps alone. Eventually this will create a single unified architecture, that looks more a lasanga then anything in an Enterprise Architecture book. (umm – I like Homer Simpson – Lasanga ummmm).
So what do we do about this? UML? it a great lanaguage for software developers but it doesn’t speak to the infrastructure. Zachman/Togaf? Great frameworks but doesn’t speak to the developer telling them what to do.
We need a reference languague and process to build architectures that allows us to say “this is the recommended solution,” this is where we vary. In the past I have called that a difference architecture (see my msdn article on this topic here http://msdn.microsoft.com/en-us/library/aa905314.aspx ).
We have to reduce the clutter in the IT world that prevents us from smooth migrations. Sadly I suspect I am part of the problem as well as part of the overall solution.
/Doc
Projects like anything invovling humans contains a series of personalities. You have the organizer, who spends much of their time trying to keep everyone together and in the same place/time. You have the project leader who is charging ahead trying to move the project through force of will.
There are the project butterflies, not directly engaged but floating through the meetings and appearing off and on (if you are a flower this is good, maybe not so much in the project world).
There are many other project types that either slow or speed up the project. However there is a new type that I’ve noticed on a couple of projects lately, one I haven’t seen before and am quite interested in.
The swashbuckler or pirate. Now based on Captain Jack Sparrow one would expect the swashbuckler to be dishonest and a negative impact on the project. But in fact the swashbuckler/pirate can have a positive impact if they appear at the right time.
Which leads to a leadership quality that is required for the swashbuckler role to work on a team. That is a quiet hand at the tiller. Someone, who is able to accept the changes required when the pirate “hijacks” the meeting.
Years ago I learned a concept called “catch the bus” where you map the person’s speech pattern and cadence, capture the conversation and then move on. The problem with the pirate is that they are equally adept at that technique – in fact they are most likely the best person at it in the room. That is how they are able to walk in and hijack so many meetings.
Now this is a good thing if the meeting is in the dulldrums or has lost it’s way. See Steven “Doc” lists excellent blogs about meeting leader patterns and anti patterns http://www.stevenlist.com/blog/. The swashbuckler will try to lead the meeting in a new direction often with the promise of gold or great riches in heading with them rather than in the original direction.
What skills do you need, to help drive that meeting back to it’s original course?
/Doc
Is change a constant. I heard a comic say this the other day and thought about it at the time (and since then as well). Change in and of itself is present in many things. Is it always present in those things?
It seems to me at times it is.
Which would make it a constant (always there) versus not being there. Within technology projects it seems to me that succesful projects are often successful because they effectivily communicated the change that was coming. If change and communication are linked, then abrupt change would be uncoupled from effective communication (communication issues talked about here http://docandersen.spaces.live.com ).
So then we alter our original thesis by saying change with effective communication is a constant?
Or do we say change is less likely to fail with solid communication, but then can we say change is a constant?
Perhaps poor communication is a change agent. Good communication is a change agent and the presence of either determines the raw nature of the change.
The answer is that change by it’s nature cannot be a constant and the comic on comedy central that brought that up kept me up for two nights without cuase (perhaps I should sue)
Communication is the constant. Our failure to communicate effectivly is the issue.
/Doc
