LiteBytes from Lustratus Research

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 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

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

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

Can you buy a SOA?

This is one of the classics of Service Oriented Architecture discussions and has recently resurfaced. Joe McKendrik over on his ZDnet blog rounds up some of the recent discussion. The heart of the issue is that SOA is not a product category because it is an architecture. Furthermore it is an architecture which requires significant focus around governance and organisation and therefore just selecting some products does not deliver SOA. Early on when SOA was close to synomious with Web Services, this was an important point to make: Just deploying a Web Services stack did not make what you did a SOA (giving rise to the delightful acronym JBOWS - Just a Bunch Of Web Services - to distinguish this approach from 'true' SOA).

However, from this entirely rational view grew the corollary that SOA can be implemented with anything. While theoretically this may be true, it can be taken to extremes: Clearly, the right product is bound to make it easier to implement SOA than the wrong product - even if you already own the wrong product. Also clear is the fact that you can buy important components of your SOA infrastructure from registries to management to ESBs. Furthermore, there is every reason to believe that software vendors will over time continue to move beyond 'just' providing infrastructure to providing larger chunks of SOA 'out of the box' - just as SAP et al do for ERP (as Jack van Hoof points out ).

Therefore today and in the future, SOA programmes must absolutely start at the architecture level and not simply select products. However, today and increasingly in the future it makes complete sense to use commercial (or Open source) software to ease the implementation:  SOA is othogonal to packaged software - not an alternative.

Ronan

Why does SOA keep forgetting about data?

Every now and then, we all hit that point when we want to stop everything and say enough is enough. I guess I have just reached that point. I spend my time working with buyers, sellers and implementers of SOA, and just about every conversation is about applications. There is a myriad of tools and platforms that are focused on being able to turn existing code assets into SOA services, building composite service and constructing orchestrated flows.....but everything is discussed from the point of view of the application.

I guess what frustrates me is that when I talk to people about what they want their services to do, particularly when you get to composite services where functions are linked together, the answer is usually two-fold - I need to run the following applications or components, and I need to access the following data. When building an orchestration flow, for example, it is often very useful to be able to interrogate data to help determine the appropriate next step in the flow.

It seems to me that most SOA products don;t really consider this. At most, they allow database calls during flows, but this is hardly in the spirit of SOA. Surely, these calls should be allowed to any data source in the SOA network, whatever the data architecture or format. This would fit with the SOA theme about offering everything under a standard interface.

Come on guys - I know data might seem boring, but it is just as important as the applications themselves.

Steve