If you work in the IT industry long enough, you're bound to hear one particular joke (well, you'll hear a number, I want to focus on this one) - "What's the only thing worse than no architect on a project?" The answer of course is "Two or more". And of course that's true, since when you put four architects in a room, you get five opinions (at least one is schizophrenic) on anything.

Nevertheless, as the joke does make clear, architecture is important. Without it, projects flounder, or worse yet succeed in a dizzying display of spaghetti code and cowboy heroics. When it does, the mess it creates comes back to roost in the future. I've visited shops where they can't make changes to their main business processes, because the COBOL code that runs it no longer even exists in source form - so they have to make changes at the compiled code level. In a very real sense, that's an architecture failure - they haven't kept up with the times, assured a realistic software portfolio management program, and maintained good software development life-cycle practices. This is not uncommon.

One thing that often gets missed in the acronym SOA is Architecture. It's fairly easy to service-enable code in this day and age - most modern solutions and platforms give you basic Web services capabilities out of the box. I even know multiple ways to reach the COBOL code (although I shudder at the thought of people writing Web services in COBOL, but even that is happening) and make it play nice in a services environment.

The point though is that service enablement is not service-oriented architecture. Architecture discusses various dimensions of software, such as how to build it, how to re-use it, how fast it needs to be, how much downtime it can have, and a number of other topics. Some folks divide architecture into business, application, and technical (or infrastructure). Others look at different levels - conceptual, logical, and physical. People with specialties (such as security) see the world as a combination of both sets, all slanted toward what is important to them. Enabling services is a good thing for many environments, but for each Service, the management, the SLAs and QoSs, the security and the transactionality of the Service must be considered. And not in a vacuum. That's where Architecture participates in the conversation. A good architecture forms a basis for the development of Services in a structured organized fashion with clean demarcations of responsibility and attention to the various performance characteristics that make a Service really work.

Realistically, that is the broadest definition of Architecture - practices that enable software to work. And practices definitely include process and not just the technical aspects of software development. In any large shop, the process of accomplishing software development is a critical part of architecture. If the enterprise concepts developed by an architecture group aren't driven into the development organization and monitored, the benefits of architecture can't be realized. That's process, not technology, but it's certainly still in the domain or architecture.

Service-oriented architecture emphasizes application delivery via discrete services over monolithic applications. Every type of architecture has its own challenges, but SOA in particular places a great deal of emphasis on layers of services and the ability to apply services discretely. Responsibilities are encapsulated outside of the services - there's usually no need for the service to understand security or service-level agreements as someone else manages that above or around them. Because each service is discrete, and to a certain extent can ignore the impact of other services, the Architecture becomes even more important, as it is the glue that holds the whole thing together and makes it function.

While two or more architects may be the worse thing in the world, remember, no architects (and by extension, no Architecture) is the next worse thing.