Prepend
2007-08-31
Anti-Anti-SOA
My google alert picked up Stefan Tilkov's post agreeing with Radovan Janecek's Anti-SOA post. So I will add in my own equally valid opinion to this chain.
To recap, Stefan and Radovan think that commonly accepted infrastructure pieces like ESBs and BPEL are actually detrimental to SOA.
While some of their points are accurate (encouraging P2P service communication rather than funnelling all SOA traffic through gateways or intermediaries), the term Anti-SOA is just provacative.
ESB/WSM/BPEL are all valid components of SOA infrastructure because they all serve valid purposes. Trying to create and maintain a single ESB or a single BPEL engine is fruitless, but so is trying to build a highly available, extreme transaction environment without orchestration, transformation, reliability, security, etc that these tools provide. (sorry about the run on).
My experience is that if you try to deliver on a good SOA without providing the appropriate infrastructure and tools, then you will fail. If you try to create a solid governance policy without delivering the support that you find in ESBs and Registries then it will make your task that much more difficult.
My take on ESBs is that they are a good place to run services and they provide a lot of needed infrastructure (security, transformation, reliability, persistence, orchestration, on and on) that you need to implement somehow. ESBs should not be treated as the end all service environment for an organization and should be designed to work with external and internal partners (especially since that line is getting blurred more and more) services regardless of what kind of implementation provisions and executes the services.
At the end of the day, an organization needs the services provided by an ESB or a BPMS or a Registry/Repository or a Management System. But it is just one piece of the SOA implementation. If a vendor comes by and says ESB = SOA then question loudly and frequently.
To recap, Stefan and Radovan think that commonly accepted infrastructure pieces like ESBs and BPEL are actually detrimental to SOA.
While some of their points are accurate (encouraging P2P service communication rather than funnelling all SOA traffic through gateways or intermediaries), the term Anti-SOA is just provacative.
ESB/WSM/BPEL are all valid components of SOA infrastructure because they all serve valid purposes. Trying to create and maintain a single ESB or a single BPEL engine is fruitless, but so is trying to build a highly available, extreme transaction environment without orchestration, transformation, reliability, security, etc that these tools provide. (sorry about the run on).
My experience is that if you try to deliver on a good SOA without providing the appropriate infrastructure and tools, then you will fail. If you try to create a solid governance policy without delivering the support that you find in ESBs and Registries then it will make your task that much more difficult.
My take on ESBs is that they are a good place to run services and they provide a lot of needed infrastructure (security, transformation, reliability, persistence, orchestration, on and on) that you need to implement somehow. ESBs should not be treated as the end all service environment for an organization and should be designed to work with external and internal partners (especially since that line is getting blurred more and more) services regardless of what kind of implementation provisions and executes the services.
At the end of the day, an organization needs the services provided by an ESB or a BPMS or a Registry/Repository or a Management System. But it is just one piece of the SOA implementation. If a vendor comes by and says ESB = SOA then question loudly and frequently.
Labels: SOA
¶ 9:14 PM 0 comments
2007-08-24
Enterprise Architect Certification
My company recently sponsored me to become a certified enterprise architect through the Federal Enterprise Architecture Certification Institute. It was a pretty interesting program and I thought I'd post a few thoughts here in case anyone else is considering plunking down the money and time.
The program is a mixture of in class seminars, online coursework and exams, real life exams and oral presentations. The end goal is to educate and certify that you know Enterprise Architecture (particularly FEA/FEAF and/or DoDAF) inside and out.
We had two full weeks of classes at the Virginia Tech extension campus in Falls Church, Virginia followed by two days of exams and presentations. In between class sessions we had about 15 homework team assignments, each requiring 1-5 hours of work, so we were kept busy through the months of June, July and August.
The Department of Health and Human Services was sponsoring the training with about 20 employees with 8 contractors also attending and paying their own way. This meant that the traditional curriculum was modified a bit to also cover the HHS Enterprise Architecture Framework.
We ended up taking four courses:
The faculty of the program are extremely experienced and their courses reflected this experience. It's hard to name a federal EA program that didn't have some work done by someone on the FEAC Institute faculty. They also brought in some speakers with case studies from DOI and the IRS' EA programs and an SOA overview by Everware-CBBI.
They have a program where you can get 16 credit hours (on the quarter system) from National University for a Master's in Engineering with an EA specialty, but I was unable to get any local universities to accept transfer credit.
Overall, the grading was a little easy but the amount of work necessary to complete the assignments was substantial. I don't know anyone who didn't end up passing.
If you're looking for a good series of courses on EA then this may be a suitable program for you, especially if you are into the federal EA space. The price tag may be a little high (~$10,000) but compare it to the costs of 2 Gartner EA conferences (~$5k) and you'll learn a lot more from FEAC. ¶ 8:43 PM 0 comments
The program is a mixture of in class seminars, online coursework and exams, real life exams and oral presentations. The end goal is to educate and certify that you know Enterprise Architecture (particularly FEA/FEAF and/or DoDAF) inside and out.
We had two full weeks of classes at the Virginia Tech extension campus in Falls Church, Virginia followed by two days of exams and presentations. In between class sessions we had about 15 homework team assignments, each requiring 1-5 hours of work, so we were kept busy through the months of June, July and August.
The Department of Health and Human Services was sponsoring the training with about 20 employees with 8 contractors also attending and paying their own way. This meant that the traditional curriculum was modified a bit to also cover the HHS Enterprise Architecture Framework.
We ended up taking four courses:
- ESXP8660 Enterprise Architecture Concepts by Kathie Sowell
- EXSP8661 Enterprise Architecture Planning by Beryl Bellman
- EXSP8662 Enterprise Architecture Implementation by Patrick Bolton
- EXSP8663 Enterprise Architecture Integration by Mike Tiemann
The faculty of the program are extremely experienced and their courses reflected this experience. It's hard to name a federal EA program that didn't have some work done by someone on the FEAC Institute faculty. They also brought in some speakers with case studies from DOI and the IRS' EA programs and an SOA overview by Everware-CBBI.
They have a program where you can get 16 credit hours (on the quarter system) from National University for a Master's in Engineering with an EA specialty, but I was unable to get any local universities to accept transfer credit.
Overall, the grading was a little easy but the amount of work necessary to complete the assignments was substantial. I don't know anyone who didn't end up passing.
If you're looking for a good series of courses on EA then this may be a suitable program for you, especially if you are into the federal EA space. The price tag may be a little high (~$10,000) but compare it to the costs of 2 Gartner EA conferences (~$5k) and you'll learn a lot more from FEAC. ¶ 8:43 PM 0 comments
