Thanks for your feedback, Robin. This comment, in particular, is the one that hits the some of the core issues:
> ...if you think SOA is an evolution of EAI, you will > end up in the same EAI-like organization where every application team > continues to do its application as usual and one integration team, > now labeled SOA team, figures out how to turn these legacy interfaces > into reusable services. A challenge in adopting SOA is understanding the types of services that an enterprise will need, and what the proper organizational approach to those types are. One high level pass could be: Application-Specific Integration Services (no/limited reuse expected) Internal Integration Services (broader reuse expected) External Integration Services One optional fourth category could be Internal, Third-Party Integration Services. A question to ask when trying to categorize these things is whether or not there is anything about this category that would justify different guidelines or a different organizational approach. The one thing that is clear to me is that some centralized governance over all of these is absolutely required. There is no clear cut rules to differentiate between the first two categories, because situations change over time. There needs to be some centralized body with a strategic services blueprint that can make the call as to whether a proposed service matches something on the blueprint, whether the service should be added to the blueprint, or whether the service can be considered application specific at this point in time. As you suggest in your second scenario, this requires strong governance. This model also implies centralized schema ownership and naming conventions, which must be applied to all categories, since an application-specific services may become an internal integration service at some point in the future. The more difficult challenge is what to do with things that are deemed to have value to the enterprise? The application team that identified it may not be prepared to take on the role of enterprise service provider, nor may they even be appropriate. Should everything that falls into this category be handled by one team? A few centralized teams (if so, how is it broken down)? Or, do we focus on the real challenge, which is change and release management, centralize that function, but keep development decentralized (scary though)? The key to this is the strategic services blueprint. Without a blueprint, there's nothing to define the category of internal integration services. The best we can do is to provide strong governance, technology standards, naming conventions, and schemas standards so that should something get reused, we've at least taken steps to minimize the effort involved. That being said, will this effort really create an SOA, where A = architecture? I think not. I think we'll have SOA where A = applications. It's a step above JBOWS, but not SOA. -tb -----Original Message----- From: Robin [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 16, 2005 9:58 AM To: [email protected] Subject: [service-orientated-architecture] Re: Centralized development? Hi Todd, I see nobody has provided an answer yet. I have been working on 2 SOA projects already in 2 different companies, one in Telecom, one in Healthcare. I see 2 facets to your question. - What activities should be centralized in an IT organization that is implementing a SOA? - What should be the scope of a central SOA competence center? Should it also manage Information Integration, EAI, ETL,... ? I think SOA is just one of the possible integration means. SOA might replace some other integration techniques like data replication or EAI in some cases but won't probably replace them all soon. Moreover, existing integration teams like the EAI guys do have already a huge enterprise-wide know-how that you must certainly leverage for a SOA project. I would recommend to group SOA and existing integration competence centers. If those integration competencies are centralized and coordinated, it will be easier to select the best integration technique for each project. Just to avoid one to be in competition with another and avoid that EII is used for integrating customer data in one project and SOA in another project leading to duplicated maintenance costs. But pay attention, if you think SOA is an evolution of EAI, you will end up in the same EAI-like organization where every application team continues to do its application as usual and one integration team, now labeled SOA team, figures out how to turn these legacy interfaces into reusable services. You might see progressively benefits because the number of adapters will decrease and you will try to limit the protocols to industry standards like Soap. This is a non-intrusive approach. In this scenario, you still have a mediator that is transforming your message or your request to something else, this mediator is the SOA team that is also responsible for the implementation and maintenance of these transformations in the middle. That scenario is perfect if you do not really control the different legacy back-end applications or are afraid to modify them. It was organized this way in the Telecom company I have been working for. But I think the full potential of SOA is to have no need for transformation in the middle. The guys who are doing back-end applications should now also provide and publish their own services. The central team should manage that service portfolio, define the guidelines, manage the semantic and might do also some limited development/transformation for services/processes that involve several applications. In this second scenario, you need a strong governance, collaboration is key. It is definitely more challenging but you do not have that expensive mediation team anymore, the service consumer and the back- end application are talking together. We have selected this organization model in the Healthcare company I am working for right now. ------------------------------------------------------------------------------------- A.G. Edwards & Sons' outgoing and incoming e-mails are electronically archived and subject to review and/or disclosure to someone other than the recipient. ------------------------------------------------------------------------------------- ------------------------ Yahoo! Groups Sponsor --------------------~--> AIDS in India: A "lurking bomb." Click and help stop AIDS now. http://us.click.yahoo.com/VpTY2A/lzNLAA/yQLSAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
