Additional thoughts, the core concepts of training

Over the past 8 months I have talked about two issues that impact architects a number of times, communication and planning/patterns. Its funny to me, having worked on a training pattern for Architects for the past two years just how much education it takes to “build” an architect. contains the taxonomy of architects. Its amazing when you think about the various specializations that we have today:
Solutions Architect
Infrastructure Architect
Information Architect
Business Architect
Operations Architect
Enterprise Architects
and there are many more possible “professions” under the umbrella “software architect.”

The next training of course will move beyond the base skills and required skills to anticipate the next generation of learning required for architects. What will that look like? Taxonomy v3 or v4 will begin to move into that space. We’ve just started on Taxonomy v2, so its a while out yet.

Visit IASA for great architect training materials!


More on architects and training

The other part of traning as we built at IASA is being able validate that training in two ways:

1. Test the retention of the knowlege.
2. Test the quality/relavence of the data

This blog is focused on the second as we know from our own schooling how to accomplish the first point (a Test!!!!).

Relavence: The training curriculum, courses and data presented in the courses were built against the taxonomy developed by IASA and has been published on for more than 3 years.

But relavence is more about changing with the times. Over the past six months we have begun the process of adding two new architecture disiplines, information and business. Additionally we have considered the various skills that architects need to have, in order to do this our group has good balence of consultants (external architects) and internal organizational architects. This allows us to blend and build out the training.

Finally in order to maintain our relavence we have a two folder approach:

1. Alighnment wth and within IASA the largest group of aligned software architects in the world.
2. Our ATC will continue to produce, evaluate ad build trainig curriculum. Our initial courses will lead to future revisions and new classes.

The future of software architect education is here!!!


Training Architects

I’ve been working with IASA for awhile, but for the past two years I’ve been running IASA’s ATC (the training committee). We have buit an amazing curriculum for architects (

We have built a taxonomy for architects and have built our training based on that reference point. The thing that I am most excited about personally is in fact the sheer quality of the classes.

From our soon to be available foundation classes to our existing presentation, operations (and many more) the classes are all high quality on-line training.

A huge piece of becoming a profession is the concept of training. You can’t say that an architect is “x” unless you can train that person, and eventually test that training to verify the person not only learned, they mastered the content.

For the first time in my career, I can say there is a training program meant to help architects become better architects.

Check out the training at you won’t regret it!!!!!


Clay pigeons don’t sing the blues

I watched a show the other day on discovery. It was all about the gentlemen who are “precision” shooters. They throw five or six clay pigeons in the air and blow them up.

What an amazing feat that is. To be able to do that. It amazed me even more when they used slow motion cameras to show the actual pellets in flight strinking the clay pigeon.

This has nothing to do with architecture – just amazed me.

In the words of a friend of mine, it doesn’t take much to please the simple minded.


Maybe he really meant to say “ta dah.”

Architecture as a magic act (add that to my quest for lighthouses and now you understand my posts). It is a great deabate – software architecture science or art.

When I was eight years old I used to color. Sometimes I was able to successfullly color in the lines (not very often really, but that doesn’t sound as good). In coloring inside the lines I was able to please the teacher and get a reasonable grade. But personally I found it less than fulfilling.

Using a templated architecture feels the same way to me now that coloring inside the lines only did when I was 8. Its the artist compeont of software architecture.

Harry Chapin, in his album “Living Room Suite” had a song that brings this debate full ciricle. “Flowers are Red” is the story of a boy who sees flowers as having many colors, leaves being different colors than just green. The teacher chides him saying “flowers are red, young man and green leaves are green.” Eventually the little boy caves in and begins painting flowers the way the teacher expects to see them. Just as I did (to get a better grade) when I was 8.

But is that the answer?

Is it possible that the solution we seek is a miexture of what is (red flowers) and what might be (yellow flowers) brought together in a single software architecture?


The cost of a solution

I’ve been in IT and Consulting for most of the past 19 years. I did a couple of brief stints in sales during that time,but for the most part I have been a technical resouce.

I find myself wondering about the cost of some of the solutions I’ve built over the years.

Realizing that part of my job is to add value for my customers, it is still hard sometimes to “see” that value.

I remember my first computer, I was a huge Steve Jobs fan then. His statement was “personal productivity” device.

Is my computer, that original personal productivity solution I signed up for providing me with that value?

I can get more done in the same time period hat I had before.

Taxes take a 1/10 of the time
Banking takes a 1/10 of the time

But at what cost? It is the conumdrum of the solution. When cost is lost in the confusion of the solution…


Are you comitted?

I love the old adage about the ham and eggs breakfast. The chicken is invovled in breakfast but the pig is committed. The difference of course is subtle but huge.

Are you committed to solving the problems that were the genesis of the requirements for your solution?

There is often a gap between requirements from a broad level and the solution that is built. Of course there are “cost cuttings” and other considerations that we must put into play.

But the reality is in many cases we fall into the gap between “desired state” and reality.

Like lighthouses we should probably measure that gap. It would give us a fair variance as we start projects.