Saturday, December 31, 2005
I have talked with a few folks at other companies that are taking this design approach. Usually they say the WSDL generation tools from services are to limiting in their capability. Anybody out there using Altova to do this? Anybody creating WSDL's from hand?
Thursday, December 29, 2005
The quote is very important when communicating with a customer. It is important to set realistic expectations for systems. Along as humans are writing the code and building the infrastructure, then mistakes will happen. Minimizing and recovering from those mistakes are what make you HA plan. Here are the tips:
-Document, Document, Document. Every aspect of the system needs to be well documented. Concentrate on "what to do if this piece fails scenarios". Make it simple and concise. Make sure everyone has it and it has been exercised. This is the single most important step when building HA systems. The best architected system in the world means nothing if the folks doing the support don't understand it.
-Buy at least the second node. Clustering your hardware even in a passive mode can save you lots of down time. Convince your client its in their best interest. If you can't, make sure there is similar hardware on site available for parts. Trying to acquire parts while your server is down is not very fun.
-If you can, buy Veritas cluster software. It's the best. If you get it, practice, practice, practice. Go over as many what if situations as possible. Do this before the application goes live.
-Make sure you have a good change management process. Changes in the environment are responsible for a lot of application failures. Developers tend to want to throw code over the wall without a lot of testing. They are under a lot of pressure to meet deadlines and will take shortcuts. Make sure they don't if you want your systems to be stable. Always have build and test systems and make sure the code is exercised there before it goes live. Your test systems should be just like production.
-Application Architecture also has to be designed with HA in mind. The construction of your applications should take into account network failures, hardware failures, database failures etc. The way you handle errors with in the application can also affect availability. More on this in another post.
-Network Infrastructure is a key component to most applications. You can have the best architecture in the world but if your network is down then your application is down as far as the clients are concerned. Make sure you work with the network guys to understand the infrastructure and where the failure points are.
These are just a few tips I've learned over the years. Once you have a good handle on your what if scenarios and how you recover from them, then you will be able to give your clients a good idea on availability and potential down time. 5 nines is very difficult to achieve and almost no one does it. Make sure you are honest with the client and set realistic expectations. And remember, just because your application has not failed does not mean it won't. It just means you are lucky. Make sure you plan for when the luck runs out.
Friday, December 23, 2005
One important lesson I have learned over the years. Architecture your application and infrastructure with high availability in mind from the start. Most of your clients will not be willing to pay for it and will swear they don't need it. Then the first time it crashes all hell breaks lose. Sometimes you have to think for them. If a business application is worth doing in the first place(somebody is paying for it), chances are people are doing to need it most of the time, which means even small outages will cause you grief.
There are a lot of different ways to accomplish this. Your available budget will help guide you. More on this topic to come.
Wednesday, December 21, 2005
Here comes the but part. Although the book is very good, I not sure Ajax is quite ready for prime time. There is a lot involved with coding a simple client. A more complex client, which is the promise of Ajax, would be difficult at best. I think it will eventually come along but tooling is going to be needed for widespread adoption. I think that will be coming in 2006 but until then get ready to get in the trenches if you want to do Ajax.
Friday, December 16, 2005
Computing power will continue to go crazy. Sun's 8 core chip that consumes about the same amount of power as a light bulb is just the beginning. All of the chip makers are going that way. More and more horsepower in smaller and smaller places.
What do we need it for? SOA of course. I expect non IT technology vendors to get into the SOA business in 2006. Refrigerators are the next big SOA thing. Just imagine your home with multiple refrigerators. Of course you don't know that they are refrigerators. All you know is you have left over pizza that needs to be kept cool. You just dynamically discover the keep cool service after you eaten all you can eat. It finds the optimal refrigerator based upon your SLA and stores your pizza at is optimal goodness. No stealing that idea, its all mine.
Tuesday, December 13, 2005
After reading Greg Wdowiak's article, I'm suddenly a lot less sure. What do you think about an Agile methodology for integration solutions? Does it make sense?
Saturday, December 10, 2005
I think the answer is, it probably varies. We tend to pay for the security blanket called support because we think they will bail us out in a bind. But in reality how often does that really happen? If you had the source and the strong tech resources, could you turn around the solution faster and cheaper? My personal experience with tech support from various companies is that all but the simplest problems are beyond their ability to help. And the turn around time is usually slow. I think a lot of times tech support agreements are like insurance. You feel scared enough that you have to have it but when you need it, you find out that it does not really cover what you thought.
I think at the end of the day having a strong core team is better than a large tech support contract whether you use open source software or not. But if you are using open source, then its an absolute requirement. Time will tell if the financial benefits are there as well.
Friday, December 09, 2005
Tuesday, December 06, 2005
Saturday, December 03, 2005
Friday, December 02, 2005
Thursday, December 01, 2005
Tuesday, November 29, 2005
Tuesday, November 22, 2005
Monday, November 21, 2005
What affect will this have on the smaller vendors who are not embracing(or reacting) to the open-source influence. Its probably to early to tell at this point but I think the head in the sand approach could be unwise for certain vendors. Especially the ones where a growing open-source community exists. What do you think? Is the open-source impact real or is it a fad that will die in time?
Wednesday, November 16, 2005
Saturday, November 12, 2005
Wednesday, November 09, 2005
Wednesday, November 02, 2005
So does open-source protect a company from vendor lock-in? I would argue that it really does not completely. The ability to modify the source code or take over the source code is a big step for most companies. After all, if that ability was well established in house, the company probably would have written the software themselves in the first place. In reality the company is probably reliant on a particular distribution agent for the software they use, particularly when it comes to support. Let's look at an example.
Suppose I am a large Red Hat enterprise customer(Red Hat has a very good distribution by the way). Let's say that Red Hat decides it is not charging enough for support and they would like to add a few of their own things into the actual Linux distribution. I'm not happy with Red Hat anymore, their direction and mine are not aligning. I decide to switch my support contract to SuSE(SuSE also has a good distribution of Linux). SuSE informs my company that they do not support my Red Hat distribution but would be happy to support(and sell) a new SuSE distribution at our site. Well now I have a migration project, a big one at that. In turns out that Red Hat already has some stuff in their distribution that is unique to them as does SuSE.
So what does the example mean? It is simple, open-source means the source is open and that is all. It does not mean vendor lock-in cannot occur. Most companies rely on and pay for support for enterprise class software. Assuming that because the source is open, switching from one vendor's version to another will be easy would be a mistake. So how do I avoid or minimize vendor lock-in? Coming up in Part 3.
Wednesday, October 26, 2005
Tuesday, October 25, 2005
Tuesday, October 18, 2005
Monday, October 10, 2005
Friday, October 07, 2005
Some of the new upstart SOA proponents warn against using proprietary technology in your SOA. The finger is quick to point to the evil expensive proprietary traditional EAI vendors as what is wrong in the world. Standards based solutions are the way to go, otherwise you get locked in and interoperability becomes an issue. These vendors typically also point out that there solution is 100% standards based and they do not use any proprietary technology.
So what's the truth to that claim? Are you going to get locked in with a traditional EAI vendor? Are interoperability issues going to plague your until retirement and be passed on to your children? The answer is yes and no. So let's add another concept, it is called the provider. Let's use Java's JMS (Java Messaging Service) as an example. JMS is really nothing more than a series of interfaces and api's with no real meat. It is up to a provider (SonicMQ, webMethods, Tibco, MQ Series, etc) to provide the meat for JMS. The interfaces and api's are contracts that more or less bind the provider into providing a set of services that are standard across the board.
Just like in life however, contracts are open to interpretation. Each vendor selects and interprets which set of api's and interfaces they are going to implement and support. So your nice JMS client over here may not be your nice JMS client with a different provider over there. So while the idea of standards sounds nice, the reality is a little more complicated. It is really up to the architect and the developers then to know the standards very well and know when the provider is deviating from them. Otherwise your highly touted portable service becomes something more akin to an anchor.
This brings me to my point (you thought I would never get there). Underneath the covers there is always a provider. And swapping out providers is almost never an easy thing to do. Spending more time on the principles of loose coupling, abstraction and common data models regardless of the technology provider will pay off in a much bigger way than spending time chasing ever moving standards and the vendors that are touting them. There are no bad standards, just bad providers. Okay I was trying to use the dog analogy but it doesn't really work because there are some bad standards. The point is, standards are a good thing but they are just a part of the total solution.
Tuesday, October 04, 2005
Saturday, October 01, 2005
The reviews goes on to mention things like self-healing(new Solaris service manager), virtualization(containers), and very quick boot times ( although I never really saw the need for this, my servers rarely have to be booted except for patches)
If you are looking for a good server operating system, Solaris continues to be at the top of the heap. I like Linux ( the blog is hosted on a Linux server at my house) but I don't think it is as far along as Solaris. No doubt though that Linux's capability will continue to rise.
Tuesday, September 27, 2005
Apparently Google thinks so. They are bragging about the size of their web index. Well at least the article explains those birthday cakes on their website.
I thought this was kind of a cool tool, actually several tools at this site. You can get site stats, rankings for more popular sites and even plugins for Firefox and IE to manage realtime subscriptions. Check it out when you have time.
CLEARNOVA has just released a platform for developing AJAX applications. Their site has some good info on AJAX and samples for learning or playing with AJAX. The Learn AJAX section on their site has samples and downloads to help. You don't need their platform for that. Their product is not free, actually pretty pricey. But still it does look interesting.
Friday, September 23, 2005
I found the article referenced above while reading Slashdot. It goes into a lot of detail on Ajax development. After reading the article, it reminds me of the functionality available in .Net with web services which has the ability to do asynch callback type functionality.
Tuesday, September 20, 2005
Mule is another open-source ESB along the lines of ServiceMix. I started looking around ServiceMix a few weeks ago. I think the thing that strikes me is the lack of tooling for these offerings. I am not a huge GUI fan, I tend to lean more toward the command line and simple text editors. However, given the somewhat complex nature of integration work especially when asynch messaging, and complex transformations/enrichment are involved; I think tooling becomes extremely important. Before these frameworks become any kind of serious player, they will have to evolve a lot. They probably will not need the kind of tool sets available from the pure play vendors but something more than what is there will be needed for more mainstream adoption.
Wednesday, September 14, 2005
Tuesday, September 13, 2005
More talk of ESB's and SOA. Iona and Loosely Coupled are definitely not on the same page. Iona is pushing this new tool set via Eclipse as open-source as well as their ESB offering. That ESB word just keeps coming up. Of course since Oracle is going to end up owning everything, it really probably doesn't matter.
Thursday, September 08, 2005
There is an article out there on the ESB as a concept. It's called Microsoft explodes the ESB. Now there is a wise authority on Enterprise Application Integration. Now if only their servers didn't have to be therapeutically rebooted.... On a serious note, Microsoft has done a pretty good job with their web services tool kit. But I would really hesitate to give them much credibility beyond that.
As far as the ESB goes, maybe the term will go away in the near future. But what is happening in the middleware layer will not. Companies still struggle with basic concepts especially surrounding SOA. And I am still not convinced that what the article is proposing is the best way to go.
Thursday, September 01, 2005
Tuesday, August 30, 2005
A good introduction to what JBI is about. However I'm skeptical that this is a better way to build integrations especially based upon the author's comment on the canonical document.
Steve Vinoski, writes "All the messages exchanged through the NMR are normalized messages, which doesnÂt imply that all messages are converted to a canonical format. As I mentioned, EAI systems already proved that translating messages into canonical formats can negatively impact performance, scalability, and the ability to further integrate systems with other integration infrastructures. The NMR avoids these Ânegative impacts by treating message payloads as opaque data that it simply sends along to the receiver."
Steve Vinoski, "Java Business Integration," IEEE Internet Computing, vol. 9, no. 4, 2005, pp. 89-91.
Not only have I not seen this performance issue, the canonical format is one of the bigger benefits from inserting an integration layer. Sure things like persisted messaging, async processing etc are nice but at the end of the day if you have tied all of your integrations together without the canonical, what are you left with? A very robust set of point-to-point integrations. Maybe I'm missing the boat here but it seems to violate the principals of abstraction, de-coupling etc. It seems that we are just moving the translation engine out of the middle layer and letting the application(s) do it. Is that really a good thing?
Saturday, August 27, 2005
A little more on the ESB and Open-Source. At what point do big companies who rely on mission critical software, start looking at the open-source offerings. Every company is unique in its tolerance for risk. The question becomes what is more risky? Closed systems from a single vendor with no control over end of life cycles or changes in product direction? Or using software from a community effort or small financially questionable company? Not an easy answer I am afraid. Both have their risks and impacts to corporations.
The open-source path. Simply having the source and being able to control your own destiny sounds good but what about in actual practice? Do you have the development expertise to handle the source, make changes? Do you really want to do that? What about support? Is your corporation self-sufficient from support standpoint or do you rely heavily on vendor support? I think the answers to these questions would have to drive your decisions. I think corporations with strong Unix and Java backgrounds would tend to do better here as a start.
Closed vendor path. The benefits here tend to be (but not always) stronger vendor stability and a more robust/dependable support structure. ie escalation paths when things go bad. There is probably a better long term outlook for the software from the vendor and a more well defined plan. The catch tends to be lock-in. The vendor will make decisions on direction based upon their business needs. If their needs and your needs align, very good. If they do not align, you could find yourself with some difficult and costly decisions.
The choices and decisions are not easy ones to make. But every corporation should be aware of the software market and the impact open-source offerings are starting to have.
Sunday, August 21, 2005
Good article from CNET on open-source software and its adoption into the corporate world. I know most companies are feeling pressure to reduce cost at every turn. Most companies are trying many different ways to do this: outsourcing, reduced benefits, pay cuts, increased automation, longer hours with fewer workers (thats your basic productivity number) and many other ways. Companies are also looking for ways to become more competitive.
Software and its associated cost remain a largely untapped source for cost reduction. And we know that software when used properly can give a corporation a competitive edge. I don't know that open-source software is a silver bullet (its not, really there is not such thing), but changing the way software is purchased, licensed and owned/maintained will eventually have a large impact on corporations and the bottom line. Some of which will be good and some maybe not so good (open-source licensing still has some kinks).
Saturday, August 20, 2005
Another open-source ESB enters the mix. These are becoming more numerous. None of these are of the quality or feature set of a webMethods or Tibco. But will they eventually put any pressure on the pure play vendors? Only time will tell but certainly something to watch.
Thursday, August 18, 2005
I've always wondered why Chrysler had more defects in their cars than anyone else. Using Windows as a critical part of the assembly line seems to explain a lot.
Monday, August 01, 2005
Integration reliability depends on the developer understanding the infrastructure. What happens when the network is down? What happens when a database connect fails? What happens if two targets are updated but the third one fails? How does the integration respond to the various runtime errors that can occur when traversing multiple distributed systems? Most of this stuff takes place asynchronously making the matter even more difficult. I plan sharing some my experiences with designing for these types of events in the integration layer. Some of the hard lessons learned.
Wednesday, July 20, 2005
Reading this article on the benefits of a POJO implementation instead of a full blown MDB EJB ie Message Driven Bean implementation along with app server. It starts to get into some of the benefits of using a less complicated infrastructure which I think is a good thing. It does raise the question in my mind, how do you account for and deploy POJO type applications. It's not as clean as deploying an app on an app server or even webMethods for that matter. Do you set up a dedicated infrastructure for POJO's or do you co-habitate with the app servers? What do others do? My thoughts are these types of apps can coexist with others. When talking JMS adapters, pushing out to the endpoints can make sense. Of course that can increase complexity, so management of those distributed objects must be accounted for. Any thoughts?
Tuesday, July 12, 2005
Friday, July 01, 2005
Interesting article about Linux cost savings. After reading the article, I'm very skeptical of the stated cost savings when compared to Unix. Red Hat Enterprise support is at least as expensive as Sun and HP (More in some cases). I think the author either didn't get the details or ignored them. The word free was used by the CIO of this company a couple of times. OSS does not mean free. And Redhat certainly is not. Hardware is pretty competitive among all the vendors, so I don't see a lot of potential savings there either unless you were comparing a Sunfire 15k against a Dell pizza box. I'm a fan of Open-Source but not a fan of unrealistic expectations or exaggerated cost savings.
The Open-Source movement definitely deserves credit for driving down the cost of more traditional Unix vendors. But the costs are now very competitive. A quick survey of the major players will show that it is a wash in most cases. Unless of course you are downloading a free Linux distribution and not buying support. Good luck with that.
Wednesday, June 29, 2005
06/28/05 - Sun Microsystems to Strengthen Its Position in the Business Integration Market With Agreement to Acquire SeeBeyond for $387 Million in Cash
Sun continues to place emphasis on it's application stack. I've noticed that their sales teams are starting to push this as well. The interesting question is what does this mean to the other pure play EAI vendors?
Friday, June 24, 2005
The ability to stop, pause, branch and restart individual steps is pretty powerful in a complex long running process. This makes complex processes more supportable. However, despite the modeler's ease of use (webMethods version), these processes can be difficult to develop and deploy. They also add a large load to the infrastructure.
Some criteria to use: long running and lots of steps. High volume, low latency would not be the best fit for BPM. Unless of course you own stock in Sun or Intel. Other things to think about, does my process frequently stall while waiting on some action? Does it have multiple points where it can stall or wait for long periods? Do I need or want visibility into this while it is happening? Does the process take different paths based upon some filter(s)?
And last but not least, do I have a big honking server(s) to run it on?
Friday, June 17, 2005
I thought this was a good discussion. One part of the discussion I was particularly interested in was the WSDL first approach to doing web services. Ie instead of using some tool to autogenerate a service interface, develop your contract first. The reason I find this interesting is that the more I work with tools the more interoperability problems I see. Plus as one of the comments discusses, this can still lead to a brittle architecture.
Thursday, June 09, 2005
Wednesday, June 01, 2005
I'm still seeing more hype than actual real implementation. This article discusses some of the issues associated with the current WSDL spec. The more I work with vendors trying to implement web services, the more issues I see with this taking off as promised. Not only do vendors have to deliver the core functionality of their product, they now have to be integration experts. Up on the latest WS specs, and all other cross platform issues. One commenter on the above article makes the point that Web Services are going the way of EJB. EJB is used today but 90% of java development is around plain old java objects. Why? EJB became to complex to implement for the fast majority of developers. It appears that Web Services could head down that same path as the standards around continue to proliferate.
Tuesday, May 31, 2005
Good to hear from folks who have actually done the switch to Linux. Look at some of the names in the article and the story gets even better. I suspect we will see more Microsoft funded research to dispute this.
Wednesday, May 25, 2005
Linux Today - SearchEnterpriseLinux: EnterpriseDB CEO: Open Source Databases are 'Unstoppable Force'
Andy use to work for webMethods as the Web Services Standards guy. We had a customer visit with webMethods a while back and I got to meet Andy. A very personable and engaging person. Not your typical CEO type. Sounds like they have a pretty good business case and plan. It will be interesting to see how much market share they can erode from Oracle. It shouldn't take to much to make them very successful.
Friday, May 20, 2005
There is a lot of discussion going around on the future of Enterprise Integration. Will it be all SOA? Will there be an ESB required? What will happen to pure play EAI vendors? Where does Open-Source fit in? Having done a lot of "Real World Integration" and spoken with a lot of individuals from other companies, I think I can safely say that Enterprise Integration will continue to be one of the more complex and challenging disciplines with in any organization.
I don't think pure play vendors are going anywhere (assuming they stay financially viable), SOA will continue to grow in hype but practical implementation will still be very challenging. ESB's will be interesting to watch. I'm not convinced that they will be able to distinguish themselves above and beyond the pure play EAI vendors (one in the same sometimes). And Open-Source will continue to put pressure on every traditional software shop which is a good thing.
There is a lot of buzz around the Service Oriented Architecture (SOA). Their are now what I call "purist" who believe that ultimately all applications will just talk with each other via the WS-* standard de-jour. While an interesting goal, not one really based in reality. The average software shop (not the Oracle's, Microsoft's or IBM's) will not have the vision or resources to embed this integration layer into their core apps. A lot of developers still struggle with basic integration concepts. The large number of standards associated with the WS-* specs, make it extremely unlikely that wide spread understanding much less adoption will occur. This will also make interoperability a difficult challenge as developers struggle to interpret the standards. Except perhaps in the larger software shops.
But what if they could? Would that really be a good thing? I'm not sure. I believe manageability of that type of distributed infrastructure would be much more costly than a more centralized approach. A lot of folks who implement pure play integration solutions end up with a more central architecture even though the products usually support a distributed model. Certainly some of the reason that happens is cost. But I think a big contributing factor is complexity. Lots of moving parts create lots of support issues.
Don't get me wrong. I think a move to embrace the SOA architectural style is a good thing. But only when taken with a dose of reality. More on the reality of integration to come.
Tuesday, May 17, 2005
Of course the other big benefit of this event, is meeting the other customers and sharing stories. It's always good to find out what others are doing and what they are experiencing.
Monday, May 16, 2005
I thought this was interesting. There is certainly a big push for IT folks to learn "the business". What about CIO's knowing the howto's of coding?
Tuesday, May 10, 2005
A very interesting article on the quality of software today. I think a lot of us can relate to some of the views expressed by the CIO's. Those of us on the integration side get exposed to a lot more technology, both the good and bad. Real time integration seems to really bring out or expose a lot of the problems.
Monday, May 09, 2005
Friday, April 29, 2005
Monday, April 25, 2005
It's interesting. I'm not really sure how business decision makers react to this kind of stuff. Promoting open-source is difficult at best in the large corporate world. Does this kind of thing help or hurt?
Monday, April 18, 2005
Growing pains for Linux. Really not unexpected. There is a lot of competition happening with the different distributions. The article makes me think of the question, can a desktop operating system and server operating system be one in the same? Microsoft has tried over the years to get their original desktop OS to become a robust server operating platform. They have made some significant progress but in my view still no where near the capability of UNIX. Now Linux is trying to compete with Microsoft for a share of the desktop market. Will that take away from the server OS?
Monday, April 11, 2005
Those who like the idea of open source and technologies like Linux have to be careful with our enthusiasms. The old saying "you don't know what you don't know" has a sister saying which is "you don't know what you do know". Okay I made that up but.... Sometimes we are so close to the technology that we don't realize how far away others are. It may seem simple but to others it is not. In the end, businesses are going to go after what costs the least and gives them the least amount of trouble.
Wednesday, April 06, 2005
You know I like Sun but Jonathan could use a class in how to "win friends and influence people". Open source has it's share of issues but it is also where the software market is moving. Trying to stop the train by parking your car on the train tracks well.......
Monday, March 28, 2005
I do have to give some props to the Eclipse folks however. Their open source product is pretty robust as everyone knows but what is more impressive is their support. I had a few issues and even stumbled upon a bug. The responsiveness of folks on the Eclipse side that helped me out was pretty amazing. I pretty much got immediate feedback that was dead on correct.
Friday, March 25, 2005
Thursday, March 10, 2005
Microsoft to Acquire Groove Networks, Combining Talents to Create Anytime, Anywhere Collaboration Products and Services
I worked with Lotus Notes early on in my career and had a chance to here Ray Ozzie (the creator of Lotus Notes) speak on a couple of occasions. A very talented individual. This is a big hire for Microsoft.
Monday, March 07, 2005
This article hits the nail on the head. The Unix community's in-fighting will ultimately lead to an even more powerful Microsoft. Linux versus Sun is a terrible fight. Take Sun out of the picture and what are you left with from the OS side? Redhat, Novell? I'm not anti-Microsoft, but I do believe competition leads to the best products.
Saturday, March 05, 2005
A good article on webservices and where it is evolving too. Especially around the rpc type of webservices versus the doc/literal type. As Jim explains, the standard for webservices is rapidly moving away from using rpc which generally results in tight coupling and a proliferation of point to point interfaces.
Thursday, March 03, 2005
So the article says he may be at Google to work on an operating system for them. Is there room for another operating system?
As I have said before, Microsoft has got to be loving this. Sun, IBM and Redhat, talking about taking your eye off the ball. You guys are killing each other and for no reason. Microsoft is focused on selling software and you all are focused on taking shots at each other. I wonder who is going to come out on top of all of this. Hmm.......
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?
Monday, January 31, 2005
Right or wrong, Open-Source is rapidly changing the landscape. I think the term re-inventing themselves is going to come into play a lot over the next few years as the traditional software vendors try and figure this out.
Saturday, January 29, 2005
ISS X-Force Database:sdk-jre-applet-restriction-bypass(18188): Sun SDK and JRE applet bypass sandbox restrictions
For you webMethods folks, this shouldn't affect your servers...but your developer's desktops might have this problem if they are using the Sun JDK. Take note in the advice that it is not enough to just stop using it, it must be completely removed from the system.
Friday, January 28, 2005
One of the bright spots is the ease of which webMethods and .Net interoperate. Of course this is assuming you get over the hump of how webMethods works with doc/literal. Many thanks to Mark Carlson for that bit of knowledge.
I haven't found the interoperability between webSphere and anything to be as straight forward. I believe that is mainly due to the way the WSAD IDE does things for you behind the scenes. I admit I'm not an expert with the WSAD but I do fine that it generates code behind the scenes that uses IBM specific classes or implementations that does not always play well with others.
Sunday, January 23, 2005
I'm still trying to get use to Eclipse. I'm not a huge fan but that is the way of the future. webMethods is porting its development environment to Eclipse sometime in the fall. So I have little choice.
Monday, January 17, 2005
I thought this was an interesting article on some kernel differences between the major vendors. It is a little old but still applies. Does this contribute to vendor lock-in? Just how difficult would it be to move off of Redhat Enterprise and go to SuSe enterprise? I am talking about large scale enterprise applications.