Saturday, February 26, 2005
Monday, February 21, 2005
This is a very interesting article on SOA and the more traditional middleware layer we think of when talking webMethods. His notion that services are in fact by their nature coupled is very intriguing. Most discussion about SOA brings up terms like loosely coupled and coarse grain services. But David makes a good point about the dependency of these lower level web services that make up a service. He also points out that they can be architected to be more loosely coupled. Understanding the tradeoffs and when to use each type of the integration is where the Architect role comes in.
Sunday, February 20, 2005
Very good article on SOA and Web Services. The demand for this next level of integration is on the rise. Products like webMethods really help enable this type of architecture. The article is talking mainly about Java skills but products like webMethods take out a lot of the complexity out of the picture.
Saturday, February 19, 2005
Tuesday, February 15, 2005
It is a shame that Redhat and Sun are so focused on each other and not Microsoft. Solaris is a very good OS as is Linux.
Friday, February 11, 2005
Interesting article, although the title is very misleading. The company only had 30 sun servers versus the 560 Windows servers it got rid of. I suspect the bulk of the admin cost they are saving come from the reduction of Windows servers. The Open Source movement and Sun are in a bit of a tift these days. It shows up in highly subjective journalism being passed for objective reporting. Of course why should tech reporters be any different from regular news reporters?
I think I'm going to give this new mag a try. The Open Source train is wide open at this point but I think this mag addresses issues with Open Source in the enterprise. Should be an interesting read.
Tuesday, February 08, 2005
This is an interesting idea. Cross platform support with no adapters necessary for messaging? This could be a potential benefit to smaller companies that cannot afford the initial investments in the bigger players. Open-Source continues to gain a lot of steam.
10. When your data absolutely has to be there a month after it happen
9. Watching a cascading implosion of dependent batch jobs at is kind of fun
8. War room sounds neat
7. Your afternoon naps are important
6. You need 24 hours to ponder a broken batch job
5. Real Time, You don't need no stinking real time
4. Month end data surprises are fun
3. You haven't learned anything in 20 years, why start now?
2. You like the client calling you every hour for 24 hours after a broke down batch
1. Cool batcharena song
Thursday, February 03, 2005
I have been thinking a lot about this topic as of late. The nature of my job, Integration Architecture, exposes me to a lot of projects within the company. Our development organizations are aligned to our business teams. The developments teams do not tend to do a lot of full blown custom development. Instead they are generally charged with implementing what I would call niche packaged applications from industry specific vendors. Implementations meaning getting the package to production with some custom add-ons like reporting, additional business logic or integration to other corporate systems.
Within each development team, the developer's skill sets may be mixed or all of one particular type of skill. This as you can imagine leads to the inconsistent application of technology across the company. Sometimes the choice of technology is driven by the package or often by the skill set of the particular application development team.
We have had much success with webMethods at our company. But I would argue it had less to do with the technology and more to do with how we have organized around it. We still see the same business aligned development teams, but we also implemented a small integration competency center. This competency center has been charged with overall responsibility of the architecture, implementation, and on-going support of the integration platform. This concentration of skill set has lead to consistent, reliable and repeatable integrations.
I'm curious to know what others see in their organizations. Should developers in large organizations be business aligned or do competency centers make more sense?