Mark Baker Hates Architecting First?

Mark, "I won't rest until you REST", Baker kicks a bit of sand on architecture first.

Oh stop it Mark - you architect first, too.

MomentumSI recently finished a large transactional web system for a customer. The customer was a startup - and had NOTHING. Guess what - before writing a bunch of code, we gave them a "Web Architecture"; we talked to them about the ilities (scalability, integrity, availability, maintainability, etc.) We recommended the infrastructure: firewalls, routers, load balancers, operating systems, web servers, web analytic engines, etc. We also recommended some design patterns and some platform choices (J2EE, IoC/PoJo, SOA-IoC/PoJo, .Net, etc.) Then we talked to them about implementations. My point is that these are things that the company didn't have - and needed before a SINGLE LINE OF CODE WAS WRITTEN.

If you're an organization that is going to do SOA - you should go through a very similar exercise. If you haven't answered the SOA infrastructure questions - or architectural configuration questions and you just start building services you'll end up in a mess. It isn't: "you may end up in a mess" or "you might end up in a mess" - it is "you WILL end up in a mess". Closing your eyes to up-front architecture is a bad idea in web systems, SOA systems or just about any system you can think of.

So, in summary:
YES - "Projects and enterprises should define their Service Architecture FIRST". If you're going to do service based systems - do it within a basic architecture. This doesn't mean go off and architect until you're blue in the face. It means lay down the basic architecture - we did it for web systems - we'll do it for SOA systems.