Sensible Perspectives

• In the 1950's, the term "mainframe" was used to describe the earliest of computers which were so large they were housed in their own building.
• In the 1960's, the term "mini computer" was used to describe computers that were as large as a refrigerator.
• In the 1970's, the term "micro computer" was used to describe "personal" computers that could fit on or under a desk.
• In the 1980's, the term "luggable" was used to describe a computer that could be "easily" transported around.
• In the 1990's, the term "laptop" was used to describe a computer that was lightweight enough to sit in your lap.
• Today, we have "notebooks" and "netbooks" and "pda's" and phones that are more powerful and have more memory than the original "micro" computers.

With the term "mini" being used to describe a refrigerator-sized computer, it's no wonder the term "nano" is thrown around loosely in many applications.  The fact of the matter is this:  no matter how small something is today, it will be smaller still tomorrow.  Computing power increases while physical size decreases.

We all remember the kids in junior high who had "calculator" watches, and now we have a company putting out a touch-screen phone in the form of a watch. (I've repressed most of my memories of junior high, so I'm not entirely sure if I proudly wore my "nerd cred" back then or not!)

The final thought I have on this is simple:  smaller form factors are MUCH harder to design for than larger ones.  Usability has typically been the sacrificial lamb on the alter of size, but it must rapidly increase in priority for architects and designers.  It's not always easy to sit in front of dual 24" widescreen monitors and design for a screen that will be 3" or less! 

Don't be afraid to start from scratch, because old ideas don't always translate.

"However, we need to keep in mind that a role is a 'hat, not a head'; the role describes the current engagement, not the totality of our interests and skills, and that, generally we will have areas in which we are comparatively stronger."

In my neck of the woods we have several ice cream shops that are part of the Bruster's Real Ice Cream franchise.  Let me tell you:  they have good ice cream.  In the dead of winter you will find people at the drive-through window ordering their favorite flavors.  I know they've certainly gotten their share of money from my family!

Every week since January, however, we've been passing by one of Bruster's locations that has a sign up that reads "Will Reopen Feb".  It's April, and they're still not open.  I don't know if this store is gone for good, but whatever the case, no "cold gold" is being served up right now.

That got me to thinking about why franchises fail.  There seems to be some variation in the actual numbers, but it is commonly reported that less than 5% of all franchises fail.  Researching the topic on the internet yields a large number of reasons, some of which seem entirely valid:

1. Location: one of the fundamentals of any good business is where you put it.  A bad location can often lead to failure.
2. Competition: knowing who you're up against, and what sets you apart from them.  Underestimating your competition, failing to distinguish yourself, or jumping in where too much already exists can lead to failure.
3. Marketing: communicating to your market why you deserve their business.  Not communicating, communicating poorly, or communicating the wrong message can lead to failure.
4. Money: investment is equivalent to commitment.  Failure to attract sufficient capital can make small bumps in the road look like the Rockies.

The real reason this interests me is simple: franchises are patterns.  When a business is successful, the attempt to duplicate that success often takes the form of a franchise.  One of the most important steps in successfully franchising a business is to derive consistently reproducible processes and getting the franchisees to follow that process.  So, in essence, it is finding "process patterns" for the "franchise pattern".

It doesn't take a genius to see where this is going: software architects and engineers live in the world of patterns.  Whether or not you consciously research patterns and apply them to your craft, you could almost certainly look at your work (if you've been at it for any length of time) and begin to see similarities in the approaches you've taken in solving problems.  If you've designed one data access layer, you've designed a hundred.

So why do successfully described patterns fail during implementation?  Consider these reasons:

1. Failure to understand the problem: acquiring a complete understanding or the problem you are trying to solve will dramatically increase your chances of success.
2. Failure to understand the pattern: understanding what problem the pattern is designed to solve will help you successfully match the "cure" with the "disease."
3. Failure to implement the whole pattern: if you find yourself implementing bits-and-pieces of a pattern, you've probably chosen the wrong pattern.

Patterns are typically designed as best-of-breed solutions, and there are usually variations of each pattern to fit specific problems.  If you find yourself deviating from a pattern, then you need to make sure you understand the full impact of your actions.  When followed properly, patterns provide solid benefits and enable you to increase your confidence in the result.

Like franchises, sometimes patterns fail, and they do, the result can be disastrous.  Most of the time, they are successful if they are followed properly. In general, patterns are in place to help avoid failure, but then again, so are do-it-yourself auto repair guides!

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.