Lustratus LiteBytes

Archive for December, 2007

Recently I featured in a podcast and wrote an article on the 5 SOA Security traps, and one particularly sticks in my mind.

The issue is about flexibility – a good thing, most people agree, but in security / governance terms it can be a two-edged sword, and so it proves to be in the case of SOA.

The problem comes down to security domains. IT implementations can be thought of as a group of structures with varying levels of security – all the way from a community village where anyone can wander in anywhere, up to castles with moats, drawbridges and even boiling oil! Imagine for example a company with a particular silo application which is highly sensitive and must be absolutely secure. This could be implemented on a high-availability cluster with hardware encryption, and even have physical access controlled by putting it in a room with locks on the door and a guard! Well, OK, this might a little over the top, but the point is the company can take whatever measures it sees fit to implement a high level security domain – think castle.

Now along comes SOA, with its philosophy of flexibility and shared, reusable services. Instead of running silos, applications become a linked set of services and logic, and the wonderful flexibility of SOA means these services could be running anywhere across the enterprise, on any platform and in any technology environment. So supposing there is a shared ‘create customer’ service, and the high-security application switches to using this service instead of its own redundant create customer code. Now, since the security is only as good as the weakest link, the security domain is broken. Someone just drilled a hole in the castle wall.

Of course, companies can take measures to ensure this disaster does not befall their critical apps. Procedures can be put in place to protect the integrity of the security domains, restricting changes to these applications and blocking them from SOA-based distribution. But many people are unaware of the exposure, and sometimes programmers, with the best intentions, might accidentally end up compromising operations. In the end, it is up to management to put in place any education programs, working practices and policies and then to enforce them. But at least forewarned is forearmed.

Steve

As it comes to the end of 2007, the dreaded market outlook surveys are starting to appear (Don’t worry we will be putting out our own 08 predictions in the near future!).

According to IDC reported in Information Week, 2008 will show lower growth in IT spending than in 07.  In particular, there will be a lower rate of growth in the US (3%-4% compared to 6.6% this year).

InformationWeek’s coverage highlights an interesting prediction: SaaS vendors may suffer more if the downturn is prolonged than license vendors as their fixed costs (infrastructure and support) are proportionately higher.  This may appear to be an ironic twist on the supposed resilience of the SaaS business model.  The downside of renewal business is that people may not renew or more likely downsize their commitment.  If SaaS companies do suffer, I suspect that it will be more to do with maturity than an underlying weakness in the model:  Recent SaaS entrants will need to get used to the business cycle and cut costs accordingly.

The article also reports the prediction of continued above average growth for Oracle.  I suspect that the other giants will also do well in 2008 as smaller vendors get squeezed between an increasing tendency among procurement to consolidate on a handfull of vendors and the downward pressure on software license pricing in general.  Start-ups in particular will be under pressure as there is likely to be a reduction in spending among the large banks resulting from the sub-prime issue and this is a sector that has traditionally fostered start-ups.  However, this sectoral tightening will simply reinforce the trend among start-ups to focus on the telcos and the government sector.

Surprisingly finally after all that doom and gloom, I am not actually pessimistic about the impact of a spending slow down if one occurs.  Tightened markets can also favor innovation over financial firepower:  As some customers become more interested in finding something different to get an increased return, those vendors who actually have something new and are capable of putting up with increased sales cycles will continue to sell and thus will be well placed when markets expand again.

Ronan

An article in ebizq alerted me to Jitterbit’s just launched “Trading Post” for integration-specific solutions.

Jitterbit claims to the “World’s most popular Open Source integration platform” – which surprised me as I had not heard of them before.

The idea of setting up sites to enable the selling of software components is hardly new (although rarely successful) and of course sharing is precisely what an OSS community is supposed to be about. What is more interesting about the “Trading Post” idea is that

- It focuses on solutions: i.e. not just source code for the bits of the puzzle but also the patterns and knowledge essential to deliverying the complete solution.  And directs potential users to the services provided by “Trading Post” providers who can help to deliver the solution and

- It focuses on both application specific solutions (such as JD Edwards) and industry specific solutions.  Again moving the emphasis away from raw technology towards problem solving.

- It provides an interesting revenue opportunity for OSS service providers/vendors who often struggle to drive revenue from support/maintenance alone.  This is because it crisply defines the value they (as Trading Post providers) can give around specific solutions.

While just launched, it is already ‘pre-stocked’ with 50 solutions which demonstrates a certain amount of apparent momentum.  Perhaps it is a model other OSS vendors should take a look at…

Ronan

Open source software (OSS) seems a great idea, particularly for segments of the market like SOA where there are lots of standards – some would even say too many.

After all, the software is free isn’t it? Of course, in reality,the decision whether to go with an open source approach to SOA is a lot more complicated than that. The key thing when considering SOA is to be realistic about the business case, as discussed by Ronan in his recent post. Evaluating the value proposition for open source SOA is a non-trivial exercise. This is a subject that Ronan goes into in much greater detail in his recent Lustratus Report, “The open source value proposition for SOA”, available from the Lustratus web store, where he considers a wide range of factors affecting the final decision.

One point that jumped out at me from the report related to the need to be sure that the chosen OSS solution is not a trojan horse. The problem is that some open source projects are actually being used as test-beds by commercial vendors, as a way of gaining valuable input and experience that can then be used as part of a future commercial offering. On the one hand, this can be attractive – after all, if a vendor is driving the project then it is likely that skilled resources will be available to ensure its vitality. But on the other hand, if the vendor plans a commercial offering then what functions will be reserved for the ‘full function’ offering? Will these be needed in the future? As Ronan states in the report,

It is common with the larger vendors in particular to promote OSS as a light weight alternative to their full strength closed source products. For these vendors, it is essential that due diligence verifies that the OSS solution will be sufficient for all current and future requirements. If this is not the case, the cost of the closed source product must be factored into the business case.

This doesn’t mean to say that these projects should be avoided – just that it is wise to consider the gifts the Greeks are bringing, and what’s in it for them….

Steve