why XML-RPC and why not plain HTTP calls? where does SOAP & REST fit in?

This is good question asked by client when we proposed XML-RPC over well (internally) debated SOAP or REST kind of service invocation. Here is why I prefer XML-RPC over sending name-value pair as in vanilla HTML POST method,

1. XML-RPC takes structured data so it has all advantages that a structured data can have, like representing hierarchy & data element presense..etc. So that semantics can be controlled, preferbly through a schema.
2. Its standard way - the data I sent is understood in same way in other end.

The second learning came from an XML-RPC based project where we needed to work with large chunks of binary data. Base64 just won’t cut it when you have to transport 1-100 megabyte entities mixed with metadata records (and other structured data). We solved this by letting an XML-RPC service return dynamically generated URLs, which the client used to fetch the resulting data via HTTP. So for the first call we used XML-RPC and for second we used via HTTP.
When come to SOAP, XML-RPC is much lighter version of SOAP.
SOAP tries to pick up where XML-RPC left off by implementing user defined data types, the ability to specify the recipient, message specific processing control, and other features.

When comes to REST, I would say its a style of exposing a service - does not define any standard format for the way the data is being exchanged (could be JSON, YAML 1.0, YAML 2.0, arbitrary XML format, etc). If I see that required operation is a resource based then I would prefer RESTful call with XML data (well you have JSON, why XML when we use REST - isn;t it?). If XML presentation of data is unaviodable then go with either SOAP/XML-RPC for standard sake (interacting with 3rd party) and REST (with arbitary XML format) if it is a internal stuff.

See this post for more specific details.

What should an Architect do in Delivery?

This is a fundamental question asked by many of colleagues that I worked with and people in my mentor network.

In my definitions, Architecture is a well layed out principles, patterns and constraints of a software solution or a product. Delivery is a process and/or mechanism governing the implementation.

Which are clearly two different & distinct entities. Processes & mechanisms in delivery has nothing do with principles or patterns used in architecture. (Unless some one want to "architect the delivery" :) which is a different ball game all together)

Then what should an architect do in delivery?

Here is my view point, an architect have to wear different caps in delivery, but he/she can still be an architect.

Here are those delivery caps,

• Guide the team & govern the implementation so that architecture principles are not compromised.
• Consume & control the change to +ve limits of architecture.
• Be a coach and influence practices so that end solution delivered is not fragile.

But how far can he/she be a "true" architect in delivery? answer to this, I feel, is depends on individual preferences & strengths. In my opinion only architects can do this job better, no one else.

The biggest mistake in business is hiring the Tallest Pygmy

Steve Davis says in his online post,

When we are hiring, especially if we are under some pressure to fill the position, there is often a temptation to settle for the best of those who we find. All too often we fall into the trap of convincing ourselves that we have seen all the talent that is available and simply hire the best of the bunch.
It is like an NBA general manager who, scouting and finding only Pygmy tribes, simply hires the tallest available and assumes that they will be able to do the job.
However uncomfortable it may be, however much additional time and work it may take, stay true to your original standards. It will cost you a great deal more to make a mistake now than it will to wait.

Another goodie/tip from him was, the problem is that we tend to hire people for what they know and fire them for who they are. Hiring is time-consuming and many business owners feel that it is hit and miss. As a result, there is a tendency to hold on to non-performers because it is easier to keep them than hire somebody else.

He is absolutely right, the fine balance, we as business leaders have to understand given the business model we work with, and priorities at hand. That's where Steve says in his story Ham & Omelet store run by Pig & Chicken, to tell us the difference between committed and involved. Rating your people based on this metric and choose the right people do the hiring job.

Does Agile practices suffer in outsourcing model?

I wonder why Agile practices suffer in outsourcing model, is that only so because of failure in maintaining good communication model/channel between team?

I understand Agile practices succeeds, for sure, given entire team is together from the same culture and with same goals, and same company.

How about when that is not the case? which is typically experienced current day project outsourcing, with teams from different geography, culture and interests (company they represent).

Does Agile challenge outsourcing? or Does Outsourcing challenge agile practices?

In my opinion outsourcing doesn't really challenge agile practices, but it challenges itself, and that challenge comes from cultural gaps, working together on a common interests & goal. Mostly soft interests IMHO i.e., willingness to share, and/or -Ve sense of job..etc. So Agile can be fragile :) if there are any impedance mismatches between teams. In an Outsourcing this is typical, mismatches can occur due to maturity of individual interacting, skills gaps & soft vrs hard goal differences. I believe this has nothing to do with Agile practices. However we have to be cautious and carefully model our outsourcing operations and transition.

Some one asked me - just because of outsourcing should we fall back on age old project management methodology - called 'water fall' model ? Hmm.. good question as such but answer to that again depends on how good are the agile practices in parent project/company. Some may attempt to water fall, if there are large impedance mismatches that I mentioned above and some may attempt to tune agile practices. At what cost & who should win is dependent on governance model of your deal :)