SOA = Innovation, Simply (Enterprise Architects too) I was "trauling the net" earlier today for new items (articles, blogs, ...) on SOA when I came across one of those articles where you ask yourself "How did they get inside my head?" - as if you are reading your own handwriting. I have documented a number of Patterns on "Effective Software Development, and the article in the link below really hits the mark on Enterprise Architects and effective architecture.
The (Business Driven) Enterprise Architect by Brenda Michelson.
In addition to the traits on what makes a good Enterprise Architect, I think attribute 10 "can innovate, simply" in the article is key to those considering or starting to execute a plan on adopting a Service Oriented Architecture. With any change, there is always room for those who prefer to "over engineer" to move in and take over. If there is not a valid requirement for SOAP for a particular service, don't use it (Note - I am not saying don't use it. It goes the other way too - if there is a requirement, use it). Well over half of the Amazon Web Services service requests from affiliate sites are non SOAP based (XML/HTTP). The ratio of SOAP to non SOAP requests has remained constant over the past two years. Why? Simplicity. Remember, in software, "one glove does not fit all". Adapt your approach and organization for a best fit on the agility scale. There are dramatically reducing returns on investment for incremental project dollars spent once the implemented requirements (functional and non functional) meet or slightly exceed the expectations of the customer. Instead, spend those dollars on other priority projects that are not yet off the ground or where implemented requirements are still less than customer expectations. If moving to SOA, start simply. If the business states that they would like to accept electronic orders/payments from business partners, that is probably a good candidate for a service (sometime in the future I'd like to have an entry here on is "Service Mining" and how to do that). But don't wait until all of the partner interface details are in from all 50 of the identified top partners if there are a few known lengthy laggards - pick 1, or pick the top 3 and make that "Version 1". Forget the requirements that someone feels "might" crop up with vendor 48 who you have not even made contact with yet. Work with the other IT solutions that will need that partner information/data (more than one known service user), and get it built, tested (working with those solutions who need the data, and the top 1 or top 3 partners), and in production as version 1 and learn from it. You will then have an adaptable, flexible, non silo'd approach (with minimal changes on each solution user of the partner data) when it comes time to bringing on the other business partners. On a more personal note, I thought I'd share that I heard from the JavaOne Conference, and my session proposal titled "Travel Web Services - Marrying Business Innovation with Java Technology" was accepted. I accepted their invitation to present, and am looking forward to JavaOne 2006 May 15-19. ( Jan 29 2006, 02:11:22 PM CST ) Permalink
