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!


Is ‘Stealth SOA’ the only choice?

Some of our recent research at Lustratus has given me the opportunity to talk to a lot of end user companies trying to get going with SOA, and a range of different roles within these users spanning all the way from the programmers to business people.

As a result, I am beginning to wonder whether the only option for SOA implementation is the Stealth model.

Leaving aside those visionary companies who are able to write off large investments on the latest new idea, or on a belief, most companies are forced to take a pragmatic view. As outlined in the Lustratus 2008 forecasts, there is a definite fracturing of SOA-related decision making between the archtiect bodies that see the value clearly, and the business-driven projects that own the budgets but do not see the need to include SOA costs in their business cases. When you think about it, this attitude from the business side of the house is not unreasonable – after all, what does SOA mean to a business unit? The discussions often go like this.

You will get get business agility and flexibility – the ability to respond faster to market changes.

– Oh yeah? When? How much do I have to invest before this happens? When do we reach critical mass? How long do I have to wait? Prove it!

The P&L will improve because we will reduce redundant code and wont write so much new stuff.

– When? What is the payback time? Why have you guys been building duplicate programs anyway? And how does that increase my project budget now, to cover the extra costs you want me to include?

But it is all for the best – honest!

– Do I HAVE to use SOA? Can I do what my project needs without? All I care about is this project, its allocated budget and the returns.

The problem is that SOA actually asks the business user for a lot of faith, just like other major infrastructure changes fo the past. One way around this impasse that many users have started to employ is the ‘SOA by Stealth’ approach. The first step is to get the SOA infrastructure assembled – ESB, Registry etc. These components can sometimes be slipped into projects without arousing suspicion, usually by claiming that the particular project needs it. Breaking the infrastructure up this way avoids the problems caused by a sudden large investment. Then, as each project is done programmers try to gradually turn pieces of functionality into SOA services – as many as can be done without drawing too much attention and impacting the budget too much.

The idea is that eventually it will become possible for IT to assemble the evidence that SOA is actually delivering benefits, at which point it becomes much easier to convince project budget holders to allocate some investment to it. In other words, the hope is that once the boulder starts rolling it


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.


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.


Can Enterprise Architects ever be “stratactical”?

I was introduced today to yet another new term – “stratactical”, in a rather good ComputerWorld article.

The definition is given as follows:

Stratactical is the word the enterprise architects at San Mateo, Calif.-based Con-way Inc. created to describe their work. “We use it all the time,” says Maja Tibbling, lead enterprise architect at the freight transportation and logistics company. “Our team takes into account both the strategic and the tactical.

I confess I found the idea quite attractive – to reinforce the importance of building IT systems and related business and IT processes and procedures that take into account strategic goals while at the same time satisfying immediate needs. Indeed, I have long been an advocate of ‘incremental strategies’ where long-term vision and goals are set, and then day-to-day activities and tactical projects are put in place that at least do not exclude the longer term picture, and hopefully go another step in the desired direction.

However, I am not sure I can extend this to the idea of having individual architects who are charged with being ‘stratactical’. This may sound like heresy, and I can imagine my good friends at IASA, the spiritual home of enterprise architects, having a fit over my assertion, but let me explain.

I absolutely think that architects can have the wherewithall to understand tactical and strategic issues. The question is whether it is practical to charge an architect with both duties. My own view is that the pressures brought to bear through tactical, often urgent, time-conscious, possibly localised projects is overpowering, and the danger is that no matter how well-meaning an architect might be, the need to design a solution fast is hard to withstand. Almost inevitably, short-term decisions will be taken that may actually go counter to the longer-term strategy.

Although confrontational, I prefer a split approach where there is a policing authority driven by architects charged with achieving the long-term benefits of the selected ‘grand design’ as well as other architects working to help tactical teams build solutions. Yes, it is irritating and time-consuming when the corporate architects raise an issue over some short-term solution, and indeed the agreed decision might be to ignore the long-term issues and go for the quick gain, but at least it will be a conscious decision achieved through some management-driven procedure. The alternative is to ask architects to make these sorts of calls in their own heads, with no ‘protection’ as can be afforded through the more formal approach – I think this is unfair on the poor architect.

So,my vote is for an architectural community that is ‘stratactical’, but a separate, management-backed body of architects charged with keeping the vision alive to balance others who are trying to address the demands of the tactical project and its drivers.