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.

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

5 thoughts on “Architecture is an attitude, not a model”
  1. I agree wholeheartedly Nick. I often try and explain the value of architecture to audiences thus:

    If you need to ingest 2000 calories a day in order to do your job, and I hold out a plate of cookies and a plate of fruit – if all you’re interested in is how quickly you can get those calories, you’ll go for the cookies every time.

    But while eating only cookies for one day is OK, pretty soon you’ll be needing that fruit. Otherwise you’ll slow down. You’ll ache. You’ll fall ill.

    We all *know* it’s important to eat plenty of fruit to keep us healthy, fit and flexible in the long term: but without prompting, few of us eat anywhere near enough.

    In the world of enterprise IT, the job of architecture is to make sure we all eat enough fruit. In other words (finally) the job of architects is to balance short-term pressures and desires with long-term perspectives that have the best outcomes.

Leave a Reply

Your email address will not be published. Required fields are marked *

six + seven =

This site uses Akismet to reduce spam. Learn how your comment data is processed.