I ran across an interesting post by Bob McIlree that discusses, among other things, that the ‘real problem’ is not what we might think.  To quote:

So…the real problem we’re solving for, as JT noted, isn’t necessarily better, faster, cheaper. In the large corporate and governmental areas, I’d argue that the real aggregate problems we’re solving for are, as examples: cost-effective front and back-end, compliant, auditable, available (pick your nines), extendable/maintainable, interoperable, and secure.

This is a soft descripton of Software Quality Attributes, which is a mechanism that you can use to evaluate and review software architecture.  (search for ATAM method).  That Bob needed to take the time to describe this is, in my opinion, indicative of just how young, and probably how misunderstood, the architecture profession really is. 

Anyone who needs to spend a lot of time telling others what their job is, is working in a new job.  Some would say “a job that is not needed,” but there I would disagree.

Those of you who say that Project Managers have always been part of software are too young to remember when Systems Analysts would solve the problems themselves.  The emergence of the Project Management profession was not an easy one.  A lot of folks questioned the need for a PM, and others resented that they got to do some of the up-front work that tends to get a good bit of the visibility.  Is it really that hard to remember that the reason we needed project managers in the first place is that developers, by themselves, had a cruddy success rate in delivering software on time?

The problem was not that developers couldn’t manage time, or tasks.  It was that there needed to be a dedicated group of people who were seperate, and were dedicated to solving the problem of delivery (time, resources, funding), seperate from development.

Where PMs solve the problem of “deliver software right,” EAs solve the problem of “deliver the right software.”  We are needed for the same reasons: because development teams, by themselves, have a cruddy success rate at delivering software in small testable components that are hooked together in carefully managed but loosely coupled links. 

We are the ones that figure out where those small testable components are, what their boundaries look like, how they are managed, and how to communicate with them.  We tie their abilities with the needs of the business: the capabilities of the organization.

For those who say that one technology or another will be the ‘magic bullet,’ I’d point out that we introduced a technology a long time ago that allows for loose coupling… it’s called the dynamically linked library (DLL).  That will solve everything!  Right? 

The problem is not that developers cannot manage loose coupling, or messaging.  It’s that there needs to be a group of people who are incented to solve this particular problem, seperate from all the other stresses of business or IT that tend to prevent these designs from emerging.  We need people dedicated to solving the problem of capability scope and component boundary definition, seperate from appliation design or technology deployment.

It’s a dual role, not unlike that of being both the city planner and the zoning board inspector.  You not only help decide where the street is supposed to go, but you ‘encourage’ the land developers to build according to the city plan.   When it works, the streets flow.  When it doesn’t, you get Houston.

To be fair, I think we are still coming to terms with the profession ourselves.

So, to Bob and all the others who feel the need to explain what EAs are for, I add my voice and recognize, that in my meager attempt to describe what I do, I am also defining it, refining it… and maybe even understanding it… just a little bit more.