When I was in college, I considered becoming a teacher, but then the thought of the pay scale as well as some time spent substitute teaching convinced me that computers might be a better way to go. I mention this because I never did get the chance to take any education courses, so I don't know if the way we teach the craft of software development is wrong, or just seems that way because I'm not fully aware of all of the issues. If this seems a strange way to begin approaching the concept of enterprise architecture, stay with me for a moment.

When I studied Computer Science, the curriculum began with a basic language course, then went into some course work on computer and number theory, and later went to databases and operating systems. While fully half of my degree requirements were spent on computers, there still wasn't any requirement for course work in software engineering or architecture. To me, this seems as though it should be the first requirement - give the student a good overview and grounding on all of the concepts involved in developing software, not just courses in languages.

A career in computers usually mirrors that trend. You start as a programmer, building small pieces of a puzzle, maybe some shell scripts, some utilities, pieces of an application here and there. Later you may own an entire application, which you may or may not have built from scratch. Along the way you get exposed to other concepts such as QA, deployment, and shared services. After years of this, you become an architect, and add the design process to your bag of tricks.

Architecture can mean many things to many people. A technical architect may deal with infrastructure, an application architect may design applications, and an enterprise architect typically leads a sweeping effort involving a corporate application and infrastructure portfolio. A program architect may be a leader of architecture teams implementing applications using an overall architecture; essentially he is a practical, or practicing, enterprise architect.

In an enterprise there is a strong need to communicate enterprise-level concepts down to application architects and developers. This includes standards, frameworks, and any other decision points that can affect a software designer or developer. Security is a good example. Without knowing that an enterprise security system, such as LDAP, is in place, an application designer or developer might design a proprietary, database-based solution for application security. Knowing that LDAP was to have been used could have saved development time in the first place, as well as removing the need for rework once the application is rolled out. It might even save time if the application had to be delayed based on the omission.

More important, however, an enterprise architecture contributes to business agility and returns value to the bottom line. With such an architecture, the point solutions and silos become sources of services that can move more rapidly to accommodate changing business conditions. With today's market conditions, regulatory environment, and privacy rules, it is more important than ever that enterprises be able to move rapidly to change the way they do business.

Also, this has a direct impact on the bottom line. Several financial services companies were recently assessed fines in the tens of millions of dollars for failing to produce required annual documentation. Avoiding a 20 million dollar penalty might be enough to finance an entire renovation program. So you can see that enterprise architecture isn't just about solving IT problems; in order to effectively address architecture strong communication is required.

Reuse is a common IT catchphrase. Services represent the ultimate in reuse but rigor must be enforced to ensure that a catalog of services is correct and is not adulterated. One off, "just for my division" special versions of services lead to organizational nightmares. It is just as much the architect's job to oppose new systems as it is to propose them. Duplicate systems are sometimes necessary - you cannot boil the ocean - but redundant functionality should be opposed at every turn. Using redundancy to avoid a service outage makes sense, but letting it stop your business from doing business because of extra systems doesn't.

So back to the basics - you need an enterprise architecture. And you need to make sure people get the high-level overview, before they dive down into the details. Just like at school, I wish someone had told me this at the start.