networking-info

JP has written up an interesting post, Build versus Buy versus Opensource . He argues that these are the three options that IT has when it comes to software. I would change these options to build, acquire, or consume and would also argue that these options are not mutually exclusive. Customers could build a system that runs on open source software and could pay for commercial support for the open source software and could integrate with a proprietary, free, but non-open source software. You get the point. It's intertwined and most of the times customers do combine the options and that's why I would say build when you have to on top of what you acquired (free or open source) and consume (services) whenever you can to avoid both. There are obviously other factors IT considers when they pick software and its deployment model but I don't see the world as black and white as open source and non-open-source. Though I see plenty of opportunities to structure and sell software to m

Well, I hope not. The enterprise architecture should always consider the security aspects of various systems – authentication, authorization, audit trail, and non-repudiation. These fundamentals do not change when extended to SOA. Any SOA implementation should address these concerns. As this article suggests , there are multiple competing standards when it comes to SOA security and I personally believe that it is a good thing (at least in the beginning). Competition keeps vendors on their toes to follow a standard that works well and satisfies customers' needs. Loose consensus over rigid agreement works well for standards. CORBA is a good example of that. It took a lot of people many years to come up with this bloated standard and eventually what people got as a standard was a superset of all the possible features that addressed all the OMG members' needs and satisfied their egos. The end result was a comprehensive but useless standard. In the SOA security world, there are c