Build, buy, or OpenSource

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 minimize the "build" part on the IT side - personalize against customize.

I really liked what the V.P and Chief Marketing Officer of GE shared during their China Olympic sponsorship efforts. He said "Our number-one revelation is that customers don't necessarily organize their buying behavior the way we structure our business." I could not agree any more and this is applicable to software as well.

SOA Security – A crystal ball?

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 competing standards, but they do not compete at the same level. If you are using WS-Federation, you can still use SAML tokens and if you are using SAML you can still use Liberty Alliance standards. All these standards will evolve and eventually the one that works well, and easy to use will win. I understand that organizations have concerns over investing too much into single identity management standard, but that does not justify organizations not investing into any security standards at all.

The companies are hard-pressed to open up their services to their partners to stay relevant in this competitive market. Don't listen to your IT department if they use the security card to scare you on your SOA efforts, instead work with them and prototype few simple ad-hoc federation solutions before venturing full-throttle into hub-and-spoke or complete identity federation solutions. This is similar to a kid learning how to bike. Use the training wheels, get rid of your fear, and once you understand how security works, get rid of the training wheels and go for a full-fledged solution. SOA security should not be a crystal ball; do your homework, follow your SOA governance and decision making framework, and most importantly have faith in your decisions – you will be fine.