Lustratus LiteBytes

Archive for the ‘risk’ Category

There has been a lot of chatter recently about measuring SOA ROI – take a look at Loraine Lawson’s recent blog for instance.

or Gartner’s results of a UK-based survey of SOA adopters. However, one of the benefits that I think a lot of people miss, or do not attribute enough importance to at least, is Visibility.

Basically, the visibility story goes that with SOA, since you break up operational components into discrete business services, then it becomes easy to monitor entry and exit to these services and hence business operations flow. This gives a clear picture in business terms of execution and performance – not just what is happening, or how many times, but HOW business is being carried out.

Gartner did touch upon visibility,

Improved Efficiency in Business Processes Execution – Isolating the business logic from the functional application work enables a clearer view of what a process is, and the rules to which it adheres. This can be measured by lower process administrative costs, higher visibility on existing/running business processes, and reduced number of manual, paper-based steps; better service-level effectiveness; quicker implementation of process iterative or of variants of the same process for different contexts.

However, the Gartner focus was only on visibility as it relates to execution efficiency. In fact, SOA-based visibility offers another benefit which, in today’s tough times particularly, can be a real big hitter for executive management. It enables management to see how process are being executed – in other words, it provides the ideal tool to monitor compliance against a growing raft of regulatory requirements across just about every industry. In order to demonstrate that your systems comply, it is necessary to be able to see what they are doing and how they are doing it. This is what SOA delivers.

So how does improved compliance management fit into the ROI picture? True, it is very hard to attach a dollar amount to compliance – however it certainly matters. With the amount of public and political scrutiny of corporations today, it is absolutely imperative that executives can show they are faithfully adhering to regulations and guidelines. Failure to do so will not only risk severe penalties, but also probably lose them their jobs! Now THAT’s a compelling business case….

Steve

As one might have expected, Microsoft tried to ignore the Enterprise Service Bus (ESB) movement for a long time, but eventually it had to do something to answer demands of its customer base looking for SOA support.

Its response was Microsoft ESB Guidance, a package of

architectural guidance, patterns, practices, and a set of BizTalk Server and .NET components to simplify the development of an Enterprise Service Bus (ESB) on the Microsoft platform

Let’s be honest. This is a typical Microsoft ‘fudge’. Microsoft ESB Guidance is not a Supported Product, but is instead a set of guidelines and one or two components. It is a Microsoft Patterns and Practices offering – in other words, you are on your own. This may be fine if you are a Microsoft development shop, but far more worrying if you are real business user with extensive Microsoft presence. It has a lot of the disadvantages of Open Source, but you still have to pay for Bizt Talk etc..

So what does the future hold? Will trying to bring the Microsoft server world into the SOA domain always be a matter of risk and going it alone? Will Microsoft productize Microsoft ESB Guidance? Are there any alternatives other than just consigning the Microsoft platform to run in isolation on the fringes of the enterprise?

Fortunately, the Microsoft model may actually be working here. I do not believe Microsoft will ever productize ESB Guidance – after all, they have had two years and are still maintaining there are no plans to do this. However, what this position does do is it encourages opportunists to jump in and develop products based around the Microsoft technology and guidance materials. An example is Neuron-ESB, from Microsoft specialists Neudesic.

So, while Lustratus strongly cautions users about the effort, cost and risk of using Microsoft’s own ESB Guidance package, the idea of utilizing a Microsoft-based supported ESB product from a specialist vendor is much more attractive. Of course, whether these new Microsoft-based ESBs are any good is yet to be seen….

Steve

The recent AFP report (Association for Financial Professionals) on payments fraud in 2008 makes grim reading for financial institutions…

…especially compared to the previous 2007 one. 30% of respondents said they experienced more payments fraud attempts in 2008 than 2007, and incidence accelerated throughout the year with 38% saying that fraud increased in the second half of the year, probably due to worsening economic conditions.

From an IT point of view, this just reinforces the need to have systems that are easy and cost-effective to change. Lustratus developed a detailed report in 2008 about the shift in the area of IT payments processing solutions, where it outlined the key elements of the new, ’2nd generation’ approach to payments processing as follows:

…the 2nd generation payments processing model needs to be based on the following key design points:-

-An extensible, service-oriented approach featuring plug-in capabilities

-Enterprise-wide, consolidated and centralized, real-time visibility and control of all payments processing activities, from anywhere to anywhere, based on a generic, standards-based payments model

-A business rules-based architecture governing payments processing functionality

- And, of course, the continued provision of reliable, efficient and repeatable payments handling as provided by 1st generation systems

The two key features that apply to thispayments fraud example are the extensible approach with plug-in capabilities, and in particular the rules-based concept. The idea behind having a business rules-driven payments processing infrastructure is that when changes are needed in the way payments are handled, these can be implemented quickly, safely and verifiably with rules as opposed to having to change program internals with all the associated implications. For example, rules could be used to enforce the use of separate accounts for handling checks or ACH payments, or having different accounts for every different payment type. In addition, rules when combined with events processing can provide an easy way to detect out of line situations and raise a red flag.

Payments fraud is only one of many examples of the need for systems to be able to respond quickly to change – and rules-based processing combined with an extensible, service-based approach to delivering functionality provides the ideal environment to tolerate that change quickly, safely, cheaply and effectively.

Steve

I was reading a post today from mainframe integration vendor GT Software…

…about its support of IBM’s mainframe speciality engines, and I was suddenly hit by the realization that in order to really add value for users, technology almost always has to be accompanied by flexibility. The two need to go hand in hand if returns are to be maximized and business risk minimized.

The specific example discussed relates to an IBM mainframe invention called a speciality engine. For the uninitiated, think of a logical processing box within the overall mainframe environment where processing is much cheaper, with different boxes being aligned to specific activities such as running LINUX operations, data access or Java-type activities. What this basically means is that if part of your workload is doing something that is supported by one of the speciality engine types, then you can choose to run it more cheaply by moving it into this engine, and in fact this can often improve performance too.

This is neat technology, offering the opportunity to reduce costs and improve effectiveness, and various mainframe software suppliers have jumped on the opportunity this offers by moving eligible workloads onto these specaility engines. However, as with any new technology development, things are not quite as simple as they seem. In the IT industry there is a terrible tendency to jump for a new technology and push everything onto it, without appreciating the implications. But, in this example, as pointed out in the referenced post,

There are many use cases where it is much more efficient to NOT shift workload to a specialty engine. Why — because, there is overhead associated with moving workload

This is typical with just about any new technology. It is great in SOME circumstances, but loses out in others. iPODs are great for listening to pop music, sounding little different to CDs and being very much more convenient, but try them on classical symphonies and you will wonder what has happened to the color and magic of the piece. The key is to use new technology for WHAT MAKES SENSE, as opposed to what is possible. There is another angle to this flexibility too. IT vendors often ignore the fact that users are not starting from a clean sheet of paper; they have existing investments and technologies that cannot just be written off. Therefore, it is important to have the flexibility to operate with whatever is in place rather than demand a specific new technology component. This is not a static need, but a dynamic one – it may be that a company might change its approach further down the line, and a rigid, inflexible technology implementation can cause terrible future headaches.

While new technology may promise a lot, it is only when coupled with flexibility over which technologies to use, for what, and when that technology can REALLY deliver its full value.

Steve

The focus of debate on Open Source is too often focused on “its free” and sometimes overstated claims about software quality.

As everybody knows, the cost and risk associated with bringing anything into an enterprise go far beyond the license costs.  For OSS, a big problem is that by its nature it can bypass the controls imposed by procurement and the legal departments.  This can lead to a range of potential risks from IP infringement to plain old version control.  Of almost equal importance to the actual risk is the fact that the risk associated with OSS can be invisible  (as the OSS use will often not be tracked as licensed software would be) and therefore undermine the whole of IT risk management.

This article covers one approach to dealing with issue:  specialist software to analyse the Open Source software.  There are of course more straight forward alternatives:  Any vendor supplying OSS as part of a licensed product should be held to account to provide support and ‘handle’ the risk issues.  For ‘pure’ OSS, there are plenty of commercial organisations who will provide a degree of quality assurance and service guarantees around projects.  It may take away from the “Its free and I won’t need to talk to legal and prodcurement” but do we really want staff bringing software straight from the web into deployment?

Ronan

SOA is a Big Thing – it transforms the business, it is a key strategic initiative, it aligns IT more closely with business goals, etc.

But this brings up an important issue for executives. How does SOA affect the business risk picture? Does it drive additional risks? Does it provide any mitigation?

Lustratus has just published a new paper, “The Impact of SOA on Business Risk“, that looks at this subject in more detail. The paper does not try to come up with a definitive answer, but instead considers the strategic, compliance, financial and operational areas of business risk and comes up with a grid of effects generated by SOA adoption, providing a framework against which companies can carry out their own risk assessments.

I believe this is an important area for companies to be aware of, with little guidance available. Bearing this in mind, Lustratus has decided to make the paper available at no charge. But for those people who cannot take the time to read the whole paper, the broad conclusion is that although there are areas where SOA drives risk, on balance it mitigates considerably more risk than it drives, and on top of this the new exposures are largely manageable.

Steve