I've just finished a 4-day software architecture course with Ruth Malan of Bredemeyer Consulting, and I must say it was a very rewarding week.  My eyes have been lifted up to see beyond the immediate horizon, and I've come away with a renewed hope and a sense of enthusiasm for the challenges that my team and company will be facing.

Perhaps the real goal of any workshop such as this is to stir the imagination and awaken the mind.  I'm sure that tomorrow after I've slept on these ideas, they won't seem so extraordinary, but at least this evening they seem relevant.  The idea that has been stirring in my mind relates to how organizations view their disparate systems and infrastructure. 

Consider this:  view your business as a city and pretend that you are flying over the city at about 5,000 feet.  Looking down you can see a lot of buildings, and in fact, that is probably the thing you tend to notice first.  Some buildings are tall and majestic, while others just seem to provide filler for the landscape. 

But there is much more to the landscape than just the buildings.  An entire infrastructure of roads, bridges, train tracks and perhaps even waterways tie the city together into a cohesive, functioning city.  From your viewpoint as you fly above the city, you notice the cars traveling between buildings, and that draws your attention to the neighborhoods that surround the city and the condominiums and apartment complexes that house the citizens.  Pedestrians stroll through the sidewalks, each with their own purpose and goals, and each with their own reason for being in the city. 

The urban landscape is broken up by beautiful parks as well as the all-too-familiar construction areas.  Buildings and roads are constantly being erected and repaired, torn down and replaced.  Towers dot the horizon and flash their lights to make sure you don't fly into them. Antennae of every sort seem to sprout from the roof of every building in sight.  A relentless stream of airplanes seems to appear and disappear from the airport with equal speed.

Then it dawns on you that beneath that landscape exists an entirely different infrastructure of water and sewer lines, cables for providing electricity, television, phone service and all the conveniences of modern society.  Tunnels house transit systems to connect far reaching parts of the city. 

All that you see was planned.  Not by one person.  Not by one architect.  Not by one planner.  Yet it all works because each piece was planned to meet certain objectives, driven by varying agendas and business goals.  Admittedly, I'm sure we've all thought that a planner or civil engineer could not have possibly laid out a particular road any worse than what they did, but overall it works remarkably well.

It seems that a city makes a good analogy for enterprise architecture.  Each building could be likened to a line-of-business application, the place where the money is made and the business is sustained.  The infrastructure of the city (roads, utilities, etc) is likened to the IT infrastructure and line-of-support applications needed to support those buildings.  The higher the density of buildings, the larger the capacity of the infrastructure needed to support them.  The vehicles and pedestrians represent the interaction between these systems and applications.

As usual, analogies can only be carried so far, and perhaps this one has already begun to break down, but it seems that there is something else here that might be missing from the discussion of enterprise architecture: the planner.

A term like "Enterprise Architect" sounds good, and there is certainly more to it than just this, but one of the top responsibilities of an EA is that of a planner.  A city planner most likely knows the planned purpose of a particular building, but is certainly not involved in the architecture and engineering of that building except to the extent it places a load on the surrounding infrastructure or deviates from established city codes.  The planner is often critical in the design to grant the final permit to build the building, and that permitting process revolves around the building architect and engineer following the established building codes for the city.

Likewise, an EA (or EP for "Enterprise Planner") is intrinsically involved in the "permitting" process for a new application or infrastructure change.  They have helped set guidelines and "building codes", and are making sure that the infrastructure is in place to support the new addition or change.  They should be careful, however, to not exert undue influence (outside of an advising capacity based on experience) over the solutions architect building the LOB application or over the strategy architect designing the new LOS application.  The role of the EP is critically important to the success of the organization, and the temptation to drop down into another’s realm of responsibility is often hard to resist, but for the good of the overall organization, it must be done.  As was emphasized in this workshop, this applies at all levels.

As you may have noticed, this is my first blog post, and as with most things in life, getting started is usually the hardest part.  So, I guess now I can say that I've started, and actually it wasn't all that hard after all.  I suspect it might be a while between blog posts, but if you wish to engage me in this dialog, I certainly welcome your input.