CEO is a bit tied up with ongoing projects for the moment, so I decided to post in the interim. The next part of the Project Estimation series should be availabe in the next day or three.
In my daily wanderings of the web yesterday, I came across this post concerning who must drive a Service Oriented Architecture. John Crupi – who happens to be the CTO of the Enterprise Web Service Practice at Sun Microsystems – rightfully points out that this process must be driven from the top down and if you think about it, it makes quite a bit of sense*.
As a developer, I can see a great deal of potential for opening up various things and sharing information between systems. I have been down deep into the guts of applications like dotProject, Mantis, and SugarCRM and I can see lots of areas for improvements, integration, and additions. My mind initially jumps to simply wrapping the existing objects in a layer of XML and then going from there. Of course, this point of view is purely from a development standpoint.
Once I put on my customer-focused business development hat, I see an entire customer-centric workflow open before my eyes. I know that a customer wants to know the status of their project. I know that a customer wants to see where their dollars are going. It makes perfect sense. Therefore, instead of simply wrapping the objects in XML, I can take a more reasoned approach and talk about Use Cases, Workflows, and the relevant views of the information. This completely changes the results.
If I can find out what the customer wants to do, what the business users need to do, and a the flow of the process, the beginnings of an API take shape. Then I don't care how a developer makes it happen, that's up to them.
Further Reading: http://en.wikipedia.org/wiki/Service-oriented_architecture
* Yes, there are exceptions to this: Amazon, Google, et al show that sometimes developers can create functionality that features can coalesce around, but is your organization a Google?