LiteBytes from Lustratus Research

What is an SOA Service - reprise

It looks like there is still some level of debate over the definition of an SOA service, according to the excellent Loraine Lawson's recent post. This was a topic covered in detail in a free Lustratus paper in 2007, entitled 'What is an SOA Service?' (catchy title). Now, I haven't read the referenced article in Loraine's post, but it seems a good time to take one more stab at this at a reasonably non-technical, simplistic level. I like to look at SOA not in isolation, which can result in the person with the loudest voice claiming the right definition, but in terms of its place in the evolution of IT.

People started with programs. Because they were hard to understand, particularly if you hadn't written them yourself, structured program was introduced including things like subroutines. Then people realized that if these subroutines and other programs were put together in an encapsulated fashion, with clearly specified inputs and outputs, they became like little black boxes that could be used to build a bigger program - these reusable components were called Objects. But now users started to have multiple platforms and application environments, and the need arose to be able to get these components to talk to each other, so messaging was introduced to provide a communications pipe, usually asynchronous in nature to provide more flexibility. A value-add layer on the communications pipe dealt with issues of different components being based in different environments, for example, and EAI (Enterprise Application Integration) was born.

But all this was still at an IT level, and for years business executives had been pushing for better business alignment of IT. So the next development was to move the IT components onto business boundaries as opposed to technology ones, through SOA (service-oriented architecture). This helps provide a business-oriented view of both design and operations. Of course, being an evolution, SOA retained a lot of the other developments discussed above - so an SOA service is not only business rather than technically oriented, but is self-contained with clearly described inputs and outputs, reusable and accessible from anywhere through a communications pipe (often an ESB, Enterprise Service Bus) that offers value add services such as transformation and routing.

So, in summary, an SOA service

• represents a clearly defined business operation
• Is self-contained and reusable
• is accessible from anywhere
• responds to well-defined inputs with well-defined outputs

I realize this is a gross simplification, but I hope it is helpful.

Steve

Whoa WOA!

Sometimes I get tired of being the guy in front of the train waving my flag and hoping I can stop or divert it. I get called old-fashioned, blinkered, boring, misguided and a whole range of other names not suitable for printing here - but at the risk of getting another postbag of objections, I want to raise my flag again with respect to WOA (Web-oriented architecture).

I read Dion Hinchcliffe's excellent article on WOA, discussing whether WOA was the future for SOA. The argument was essentially that SOA has not delivered the expected benefits, but WOA can. Essentially, WOA is all about arranging information in terms of resources that are accessed through HTTP in the same way as URLs. You have GET, PUT, POST and DELETE commands just like in most message-based SOA solutions. The resources are manipulated by components such as browsers etc, and it is the responsibility of the component to understand the representation and state changes of the information.

I have no problem at all with this - sounds great. My problem is the suggestion that this is the future of SOA - the implication that in some way SOA has failed and WOA, close cousin that it is, is the natural evolution. I have a couple of major grumbles here.

Perhaps the biggest is that WOA is all about a connectivity / integration architecture - a technical network really. The fundamental change with SOA from what people have done before is that SOA services are on business boundaries, not technical ones. Hence a SOA service is something that makes sense in business operations terms - eg Get Customer Details. Perhaps the implication is that in WOA the resources are also synonymous to business ops, but then how are they defined when the responsibility for understanding their representation and behaviour lies exclusively with the browser or other component accessing them?

Another particular gripe I have is that whereas SOA is based on a messaging bus to do the transfers, such as an ESB or a reliable messaging pipe like WebSphereMQ, in WOA all comms are done using HTTP, presumably with reliable delivery being provided through WSReliableMessaging ha ha. In fact, doing once and only once delivery of messages is really hard, and as we all know from the number of times we receive duplicate emails or none at all, HTTP is not brilliant at it. As for WSRM, as is often the case with standards developed to try to counter a dominant market de jure standard, the lowest common denominator approach required to get agreement across a range of parties renders the standard very questionable in terms of maturity. 

Apart from that, I applaud WOA. As an analyst I am always delighted to see a new idea come to fruition, particularly with a new buzz word that has to be explained. After all, that is how analysts makes their businesses work! And to be serious, I see real value in WOA - but if people start looking at it as a replacement for SOA then I think users are in for a shock.

Steve

IBM events make an impact on SOA

IBM certainly seems to see SOA as a key initiative, if its annual SOA show is anything to go by. The IBM Impact 2008 even in Las Vegas attracted more than 6000 attendees, and they can't all have gone just for the weather! But the most salient aspect of the event as far as I was concerned was the 'event' support - not the army of people ensuring the party ran smoothly, of course, but the addition of the WebSphere Business Events product.

Event handling has always been possible with WebSphere, but it was messy. Triggers could be set on different queues, and conditions could be detected in various ways, but the whole thing was pretty technical and complex. However, IBM's new product, based around its acquisition of AptSoft technology, delivers exactly what business users are looking for; the ability to write business rules in their own language that can control operations.

One of the key characteristics of SOA is that it breaks monolithic application stacks into individual services, each executing a discrete piece of business functionality such as 'Get Customer Details' or 'Book Delivery Date'. In addition, information flowing in and out of these services is cleanly architected in a standards-based fashion, and is therefore easily accessible. But this opens up a magnificent opportunity to deliver business control over operations through the use of business rules that implement corporate policy by changing execution and flow.

For example, if a bank wants to offer students the opportunity to make payments from their accounts with no charge, a business rule could be written that says 'If account holder is a student, then skip the charge calculation step'. This is a simple example, but with the addition of a correlation capability IBM has ensured that much more complex rules can be put in place. Consider the type of rules needed to mitigate the risk of fraud, for instance, where multiple conditions from a range of different systems would need to be assessed to detect suspicious activity patterns.

The key is that these things can be achieved with the use of business rules that the business analyst can understand. This makes change quicker, and reduces the risk of misunderstandings between the analyst and IT technical staff.

With the addition of WebSphere Business Events support, IBM SOA has finally grown up. I guess the next step could now be a comprehensive BAM solution......we can but hope.

Steve

Breaking the SOA logjam

One of the 2008 forecasts in the annual Lustratus look ahead is that SOA decision-marking has become fractured in most companies, with clashes between architects / IT who 'get it', and business-oriented budget holders who don't. In fact, this problem is turning out to be so severe that it is causing SOA adoption to stall at many companies - although enterprise-wide decisions may have been taken to adopt SOA, projects steadfastly refuse to enact this because of the extra costs, at least initially.

The roots of the difficulty here are twofold: understandable cynicism and the need to reach critical mass of SOA deployment before benefits start to show. However, there may be a light on the horizon, as discussed in more detail in the Lustratus Whitepaper, 'Justifying SOA to the Business', available for free from the Lustratus webstore. For business audiences, it may be that the enhanced business visibility offered by SOA could be a compelling benefit to justify the extra investment, and this visibility becomes apparent immediately the project is complete - there is no need to wait for critical mass to be achieved before seeing the benefit.

Hopefully, this angle of attack may succeed in breaking down the SOA adoption log-jam, enabling companies to flow smoothly to widespread SOA adoption.

Steve

Secure mainframe SOA-in-a-box

I was reading the announcement from Layer7 about its 'SOA-in-a-box' for IBM mainframe users, and a number of things struck me. First, I am SO PLEASED to see someone remembering that CICS is not the only mainframe transaction processing environment in use today. A significant number of large enterprises, particularly in the finance industry, use IBM's IMS transaction processing system instead. With the strength and penetration of CICS in mainframe enterprises, it sometimes seems like these users have become the forgotten tribe, but investments in IMS are still huge in anyone's numbers and it is a smart move to cater to them. I am sure that the fact that this solution serves IMS as well as CICS users will be a big plus.

The other point that struck me was that I have felt for some time that, with the security/intrusion detection/firewall/identity management market seeing such a shift to security appliances, it was time vendors thought of piggy-backing functionality onto these platforms. Of course, one reason for having an appliance is to provide a dedicated environment to address issues such as security, but in truth these appliances are rarely used to anywhere near capacity. Therefore it makes a lot of sense to optimize the use of the available processing power rather than slavishly locking it away where it can;t help anyone.

Finally, I have to admit my first reaction to this announcement was to worry about how good connectivity would be to the mainframe. Dealing with mainframes is an arcane area, and I was not aware that Layer7 had any special expertise or credentials here, but I see that GT Software is apparently providing the mainframe integration piece. This makes me a lot happier, since this company has been dealing with mainframes for 20 years. In fact, Lustratus did a review recently on GT Software's Ivory mainframe SOA tool, which is apparently what is included in the Layer7 box.

Anyway, on behalf of all those IMS users out there, thanks Layer7!

Steve

Will TIBCO be next on the acquisition block?

So, now that BEA has finally fallen to Oracle, who will be next? My money is on TIBCO.

TIBCO Software has done extremely well since it came into existence from its origin as as Teknekron. Initially an EAI (Enterprise Application Integration) company, it quickly expanded to take on challenges such as Workflow, Business Process Management (BPM) and service-oriented architecture (SOA). More recently it added Business Intelligence and Analysis to its portfolio, strenghtened by the acquisition of Spotfire last year. TIBCO products are well-respected, and it has a strong and loyal customer base.

But with BEA going, and webMethods being taken out by Software AG, it is more or less alone as a pure-play middleware player left. In addition, anyone looking at the results for its 2007 fiscal year (ended Nov 30th 2007) will immediately realize that it is an attractive target. The question isn't really whether TIBCO will be bought, but by whom.

Names being kicked about include all the usual suspects - IBM, Oracle, SAP....but I reckon that HP might snatch the prize. It missed out on BEA, but perhaps on reflection TIBCO is a closer match to its needs.

Steve

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

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