I've stumbled upon a presentation by Ron Jacobs on the Software architect's role (via Shahid Sah's blog) called Architects and the Architecture of Software. In this presentation Ron compares the architect's role for that of an explorer, an advocate and a designer.

While I can go for the designer bit - although I don't like the heavy analogy to building architects (I know, I know I have that as well in my software architecture presentation - but at least it is no longer there in the next version)

However I would personally replace advocate with a mentor and explorer with a polymath or renaissance man and add a leader and visionary as well (although Ron mentiones that as part of the discussion on explorer)

Advocate is someone who observes, listens and gives advice - but a mentor is someone who helps others reach the right decisions and help them learn and evolve. I think that has much more value. I want a Socrates not an Alan Dershowitz on my team

An explorer looks for new grounds and is a bit of a visionary - but a renaissance man is both knowledgable and inventive. As a development manager I rather have someone who knows what he is doing, understand the wider perspective and can find solutions to my problems - and not someone who would take me on a road to uncharted territories. I'd take Leonardo Da Vinchi over Columbos ( who accidently gave the competitive edge to spain and didn't even know it) any day.

A visionary and leader is also important - you want someone who is able to look far and that can help your team get there- I guess that is somewhat akin to an explorer (in the sense Ron mentions) but again I'd rather have a Martin Luther King than a Columbos (though lucky wouldn't heart).

But hey, that's just my opinion

How can a Service handle  computational heavy tasks in a  scalable manner?

You can get the full pattern from here

[This is an early draft of one of the Performance, Scalability and availability Patterns from my SOA Patterns book]

I've added a section called SOA Patterns on the site while holds the current draft for the table of contents of the SOA Patterns book I am writing. The section lists the problem each pattern addresses as well as links to published patterns. Also, you can  use this to monitor my progress (patterns that already have their problem written down already have drafts; the others are in-progress or not started).

I am currently working on chapter 4: Security & Manageability patterns (not counting delays mentioned in the previous post).

Also, as I think I've already mentioned, I'll make public at least one pattern per month, if you are interested in a specific pattern in particular (from those which are ready - now chapters 2&3) drop me a note and I'll publish the one that gets the most votes

My editors at manning think that my chapter 1 of the SOA patterns book is not good enough.

They basically say that the chapter talks about too much theory vs. the other chapters which contain much more down-to-earth stuff (e.g. Edge Pattern, Aggregated Reporting Pattern, Decoupled Invocation Pattern ). Also they’ve said that I spend too many pages explaining what architecture is or taking about distributed system before I get to SOA – which is the topic of the book.

The way I see it, understanding architecture and distributed systems is essential to understanding SOA (from the development side i.e. when you want to design and build services). For example the discussion on quality attributes explains how you can use scenarios to find architectural requirements (and each pattern then has a section on relevant scenarios to help you find if the pattern is applicable to your needs)

I would be very interested in hearing what you have to say (either as comments here or emails to me) about the Chapter’s structure and content (considering most of the books will be patterns like the Edge pattern)

Thanks in advance