LiteBytes from Lustratus Research

Will mashups mash up your infrastucture?

One of the forecasts in the Lustratus predictions for 2008 Insight, available free of charge from the Lustratus web store, deals with the emergence and adoption of mashups. At this moment it is unlcear how fast mashups will be adopted, but Lustratus thinks that any serious adoption will place massive strain on enterprise infrastructures, causing the unwary to buckle and collapse.

Mashups seem great. The user is suddenly in a position to create his or her own page layout with all the business applications needed to carry out this user's activities. A great productivity boost, perhaps, but what are the impacts on the enterprise? Basically, as Lustratus points out, every desktop becomes an application. Instead of an IT department having to worry about 10 or 20 applications, all of a sudden there are 100s or even 1000s. Worse still, while traditional IT-controlled applications are usually controlled fairly rigorously with procedures, policies and management practices, the world of mashups could well be more akin to anarchy.

Fundamental to a productive mashup will be the need to drive the different business services required by the particular user, and therefore services will suddenly become tools used by hundreds in many different ways. All of this activity could create huge traffic increase as well as a generally uncoordinated style of operations, causing major difficulties for the infrastructure software trying to hold everything together.

Well, OK, maybe this is a little negative - but the point is, enterprise architects and management should start considering these issues now. Trying to sort this out when the genie is out of the bottle will be a lot more difficult.....

      Steve 

SOA Communism vs Corporate Capitalism

During a nice break for the Holidays, I got to thinking about SOA and its similarities to communism, and on my return I have been chatting to a number of SOA users and have confirmed my suspicions. SOA is just a communist plot!

Seriously though, there is a real issue here that is starting to affect companies as SOA penetration increases. Once upon a time, IT investment was funded primarily through a central IT budget with all business units having to share the burden, but over the years this became unacceptable to many who wanted a more capitalist view where funds came from the people generating the business and were justified based on returns. So nowadays IT budgets typically fall into two pieces; a central component for the IT 'infrastructure' that everyone shares, and project-based funding attached to specific business initiatives.

Then along comes SOA. In its simplest terms, SOA is about two things - packaging functionality in business services, and encouraging the sharing of these services across different business needs. But who owns these services / is responsible for funding them? Are they infrastructure? Well, not really because they are business-driven. So are they funded by a project? But in that case the project is now having to fund something being done 'for the good of the whole'.

This problem can be seen more clearly if we look forward. Imagine a company where SOA has become a way of life, and all applications are now made up of shared SOA services linked in different ways. Does that mean everything is now infrastructure and should be centrally funded? Then that takes us back to the centralized funding days, losing the link between business need/return and targeted investment. In reality, this introduces the principles of communism, where everyone owns everything, and the problem for companies is that this model stifles business performance and progress. Perhaps one way around the problem is for monitoring and management software to keep pace with the changes, so a clear picture can be built of which business operations drive which services. At least this would provide some more granular level of investment/return linkage.

However, my personal view is the problem will sort itself out - once the initial funding hurdle of SOA has been overcome, project funding to achieve a particular business end will be happy to build the required functionality in 'SOA mode' because it will be just as cheap as not doing this, and this will have the convenient by-product of helping other projects. In other words, the kick-back against SOA by projects today is based on being forced to increase investment 'for the good of others'. If SOA works out right, the future should see projects tomorrow investing less but also seeing others benefit, a much more palatable situation.

Steve   

Can SOA be bad for your health?

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

Tight times ahead for software industy will favor innovation

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

Jitterbit kick-starts an OSS solution marketplace

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   

Beware of the OSS Trojan Horse

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

Building a realistic business case for OSS

Some proponents of Open Source Software can be their own worst enemies in the efforts to distance themselves from the traditional software license based vendor.  For instance I read in a recent article that two of the benefits of OSS were: 

“Never again will you fear the BSA (Business Software Alliance, not the Boy Scouts!) knocking on your door wanting to perform a software audit.  The BSA even takes out advertisements on Google search pages for and up to $200,000 reward a disgruntled ex-employee can receive for reporting your company to the BSA! That's quite a powerful motivator.”

And

“In the world of Open Source Software, if you can't wait on someone else's schedule for a new feature, then you add that feature yourself. What? You don't have programmers on staff? You can always outsource to a programming company and have them do it for you.”

To translate OSS is really great because you won’t get nailed for breach of licensing agreements and you can always write your own software.  Not exactly compelling arguments for any business case!

While there really are arguments for ”going OSS”, most firms will not take such a strategic move.  In most cases, OSS is used to solve specific problems – just like any other piece of software – not change the world.  And the business case covers the same territory as for closed source: a combination of technical evaluation and assessment of cost and business risk.  The second point is challenging only in that we are less familiar with evaluating OSS in this way - and isn't helped by over enthusiastic promoters of the OSS religon.

Ronan

SOA helps with flatter supply chains

One of the benefits of SOA that I keep banging on about is visibility, and I read a great article recently that showed how this can benefit companies that are transforming their supply chains. I thought it worth adding some background to the high-level claim that SOA really helps with flatter supply chains.

To recap, in traditional IT architectures, applications and programs execute a range of business functions 'under the covers', making it hard to see what is happening to individual process steps. The problem is that the IT assets are deployed on IT-oriented boundaries (programs) rather than business-related ones (business operations). In SOA, IT components are arranged into business services that correspond to distinct business operations or steps.

IT monitoring and management tools can see when different IT steps are called and executed, but in the traditional example this information is really only relevant to the IT department itself. It means little to a business analyst. However, in SOA this same information actually represents calling and executing business steps, giving a greatly improved level of business visibility. 

The referenced article discusses the problem facing many companies as they face the need to transform supply chains. The argument posed is that whereas in the past manufacturing has been located close to the customer, with just-in-time supply to minimize inventory levels, globalization is increasingly breaking this model and creating long, complex, flatter supply chains that cross country borders and have to deal with varying levels of regulation and management along the way. Optimizing these flatter chains requires a clearer visibility of what is happening where, throughout the extended business process. Collaboration is important too.

As a result, companies are turning to SOA to help with these problems. It provides a level of standardization, making it easier to get all parties collaborating, and most importantly it offers the improved business visibility that is required.

As a purely academic postscript, my eyes were really opened wide by a new spin on supply chain management that had never occurred to me. The article points out the challenges of having to work the supply chain 'in reverse' - that is, what to do when a customer sends the goods back! Ouch!

Steve

Putting the suit on Social Computing

I have previously written about the application of Web2.0 technologies to enterprise problems at a general level.  In the past, I have taken the view that the Web2.0 technologies may be of interest, but the enterprise application of the 'social computing' side of Web2.0 was still very immature: the general value of collaboration was clear but how it would be implemented and which pressing business problems it addressed were not.  This lack of maturity was reinforced by fighting talk from some Enterprise 2.0 proponents about changing the way enterprises work by up-ending hierarchies and claiming that when the "facebook generation" moves into the workforce all will be changed.

However, I think that the concept is now maturing as can be seen from announcements from both BEA and more recently Progress around what BEA calls Enterprise Social Computing  and Progress calls Socially Oriented Architectures.  What is promising is that both announcements focus on the application of social computing (and it's ability to enable fluid communication and information sharing) to solve business problems.  In the case of ESC (an acronyn to make any tech marketeer smile), the application is to the area of process improvement.  As my colleague, Steve Craggs explains in his new insight on ESC and SOA (which is free to download at the moment!): 

"If a company can understand a little more about how employees are solving their day-to-day work-related problems, it should become possible to establish best practices or carry out training to improve employee performance. The traditional approach to solving this problem is to engage an external business process re-engineering expert. However, these experts are both expensive and disruptive. In many cases, the best practice expertise is already there—it is just that it is un-communicated, locked in the heads of one or more expert employees."

And of course, it isn't a huge leap to realize that SOA is a fertile place to start using such an approach - as this requires a high degree of communications across organizational boundaries and involves tech-friendly staff more likely to adopt new concepts like ESC.

Ronan

User experience with mainframe SOA provides interesting pointers

Yesterday, I had the pleasure to host an Integration Consortium webinar on the topic of mainframe SOA. The user experiences were provided by SunTrust, a major US bank, and I found them most illuminating.

One point that struck me was to do with ownership of the new services, from an organizational point of view. The issue here is that, although services representing mainframe transactions clearly fall into the domain of the mainframe programmer, the concepts of SOA and often the related tools can be quite alien to these programmers - having to worry about SOAP messages, XML, WSDL and web services standards for example. SunTrust cleverly selected a mainframe SOA toolset that masked much of this complexity, offering a development environment that COBOL programmers felt comfortable with. As a result, mainframe services are built and owned within the mainframe team, which is where they belong to be honest. To complete the picture, the tool transparently handles the service deployment, creating WSDL and exporting to UDDI registries as required, ensuring that SOA users will see familiar services.

The lesson seems to be, be clear on who you want to own what, and then choose a toolset that supports that decision. The alternative is a confused mishmash where no-one knows who is responsible for what.

Steve