LiteBytes from Lustratus Research

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 

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.

Steve

Open Source SOA - Are we there yet?

I am often asked whether open source (OSS) SOA is a reality yet - whether it is ready for prime-time, as they say. The answer, as is often the case, is 'It depends'. There are many OSS projects in the marketplace around ESBs, Integration and SOA, but just having a project in place is a long way from having production-ready software. For a start, there are the questions of maintenance, support and even indemnification against possible future legal activities. The most useful projects are those that have an associated commercial company addressing these types of areas.

However, the other aspect to consider is that most opern source projects are started and driven by technically adept programmers, so they tend to be oriented towards programmer usage. In SOA, this may be acceptable, depending on requirements, but it may also be desirable to have a solution more oriented to business analysts. They key is to be clear on what you want, and on what is being offered.

For a longer discussion on this topic, Lustratus has just published a free assessment of one particular OSS integration vendor, MuleSource, and its open source offering Mule. This paper considers a number of these types of key questions over OSS SOA, but of course in the MuleSource context.

Steve

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

Use a hot-house to get better productivity

I was keynoting at the DeutschePost SOA Days technical seminar held in Bonn, Germany last week, and while I was waiting to present I sat through a very informative presentation from a large telecoms company about its efforts with SOA. However, one point that really caught my attention was the fact that the company has had some success with improving productivity through focusing on 90-day cycles. This extremely challenging timeframe is assisted greatly by the SOA approach used by the company, but a key element is that new projects start off life with a 'hot-house' activity.

The idea is to gather the core team of people involved in the project in one room, for however long is required, to spec out the project and select the implementation approach. This looks at the business and IT requirements and implications. What I love is that this 'hot-house' is carried out in a special room where there is only local networking available (no internet or email), and it even has mobile phone jammers to block calls. Results appear to have been extremely impressive. The hot-house sets the scene for a rapid development effort. Admittedly not every 90-day cycle completes the project - it can determine that another cycle is needed for additional research for example, but project delivery has definitely speeded up.

As for me, I just want one of those mobile phone jammers - I would love to take one on the train, and turn it on intermittently.....

Steve

Reuse still seen as top SOA benefit

I was interested to see, in a recent survey carried out by PMP Research, that the top-scoring benefit expected from SOA adoption was still reuse. The research was documented in the September 2007 issue of Conspectus, and on 1 1-5 scale 'Business process service re-use' scored 4.1 on the benefit list, followed closely by 'provides a more effective integration platform'.

Many SOA advocates talk about SOA being fundamental in terms of building a flexible and adaptable infrastructure while aligning IT and business requirements more closely, resulting in a more agile and effective platform for supporting business needs - so how come reuse still tops the list?

My own view is that reuse is simply the benefit that is the easiest to take in. The others I list above are very powerful, and can promise significantly more overall business value, but they require more than just a technology change. They require changes to working procedures and practices, and much better communications between business and technical communities. So, perhaps, in the eyes of the pragmatic respondents, reuse suggests itself as a reasonably obvious gain which even has a fairly clear and measurable monetary return attached. Reducing redundancy should have a direct correlation on application maintenance costs, for example. And on top of this, it can deliver value from a purely IT point of control (although the value will increase if business departments are involved too).

Steve

Don’t forget productivity when selecting SOA software

When I talk to vendors of SOA software about their offerings, I always focus on the tooling provided with the product – from development tools to deployment tools to life cycle management tools.  Of course vendors will claim that their products are easy to use and highly productive.  Unfortunately, these claims are often not properly challenged as products are being selected for SOA projects based primarily on functionality and ‘enterprise’ attributes.  This is partly because it can be quite hard to establish just how productive the software will be when used outside the demo or pilot comfort zone.  I said unfortunately above because anybody involved with integration projects (SOA or otherwise) will understand the high proportion of effort spent on dealing with the unexpected incompatibilities or consequential issues:  Effort which can be significantly reduced with good tooling.   

Another part of the problem is defining what we mean by easy to use and productive.   In particular, whether a tool is easy to use or productive is closely coupled with who will be using it.  A productive tool for an expert java developer is very different from a productive tool for a business analyst.  Without unfairly blaming our marketing friends, there is a tendency in the industry to assume anything GUI based must be suitable for business analysts and so long as it works in Eclipse, java developers will be happy.  (For instance, I remain to be convinced that the business process execution language, BPEL, is something any business analyst would use - pretty interfaces or not) Needless to say, reality is much more complex and when evaluating the tooling around your preferred product makes sure to match the capabilities against your developer base and not be fooled by the apparently pretty pictures (or lack of them).

Ronan

Is your legacy integration just a veneer?

Summer seems to be a time for reading through that huge pile of interesting articles and magazines that you can only find time to look at on vacation. On flicking through my own mountain of stuff, I came across the Q2 edition of Financial-i, a magazine targeted at the Financial Services industry. One point to jump out at me was a comment from Paul Joynt of Nordea, a Scandinavian finance house.  Paul was pointing out that SOA does not necessarily solve the problems associated with legacy integration.

The article, 'SOA - is it worth the effort', is available from the Financial-i site if you register, but Paul comments that covering a legacy system with a wrapper "so it looks like what you want" still leaves problems with the next level of change, because "it's only a veneer".

I think Paul has hit on an important point here. Different vendors in the SOA space have different approaches to addressing the problem of integrating legacy systems. Some will simply 'hand off' the request for legacy information to a tool from the legacy supplier - in the case of IBM mainframes this might mean using WebSphereMQ as the bridge, for instance. Others might approach the problem in some sort of screen-scraping or other interface simulation approach, where the legacy application is fooled into thinking it is running in its normal mode of operations. Yet more may generate code-based wrappers for each individual need, to be executed whenever a particular service is required.

To me, this all sounds too much like veneer in Paul's terms. Although this might address immediate needs, future changes will continue to generate substantial additional work and the generation of more and more 'special-case' code and wrappers.

Instead, the best of breed legacy integration solution should embrace SOA and integration rather than try to fool it with wrappers designed to seal off the legacy world from the outside. Legacy integration should be about making the legacy system a full and active participant in the service definition and execution. For example, orchestration should be possible both outside and within the legacy environment. Services should be built with full participation from both sides. By taking this approach, the best of breed legacy integration tool will ensure that future changes will become easier, quicker, cheaper and more reliable.

For more information on the whole subject of legacy integration, specifically in the case of mainframe systems, Lustratus offers a free paper on the subject.

Steve

SOA for the scientific community - a practical example

I was intrigued to discover a discussion paper from the University of Southampton in the UK about how SOA is helping the scientific community. The paper, entitled 'A Collaborative Orthopaedic Research Environment', describes how SOA has been used to enable a Virtual Research Environment for orthopaedic researchers to collaborate in the design, analysis and dissemination of experiments.

What I found most interesting were the reasons for using SOA as the base architecture for this environment. The key objective, based on input from the specialists who will use the system, was to provide an easy way to share scientific data and results from collaborative research. However, it was deemed essential that the system could also evolve based on the changing requirements of the user community. One example of change that the paper gives is that of knowing which of a wide range of protocols will be followed for a particular clinical trial. Not only do these vary considerably, but it appears they are also susceptible to changes in regulations.

The solution decided to utilize a coarse level of services, essentially using just four - to manage the trial-related data, analyse it, submit and disseminate related research articles and support discussion forums. However, through the reliance on SOA, these services are flexible and extensible, making it much easier to address the changing needs of this particular scientific discipline. In addition, the services are reusable, and some could therefore be usable for other scientific areas.

It's good to see SOA being used to effectively address clear user needs in this way.

Steve