Lustratus LiteBytes

Archive for the ‘microsoft’ Category

Micro Focus announced its latest mainframe migration tool, ReUZE yesterday – and once again it has completely missed the point.

The background is that for companies looking to move off the IBM mainframe, Micro Focus has been offering solutions for a number of different target platforms, but in each case the solutions have been based around the old emulation concept. Once again, it seems the company has fallen into the same trap. As the press release states

Unlike other solutions which insist on rewriting mainframe application data sources for SQL Server, or removing mainframe syntax from programs, the Micro Focus solution typically leaves the source code unchanged, thereby reducing costs, risk, and delivering the highest levels of performance and reliability.

The highlighted end to this statement is where I have a problem. Micro Focus seems to think that by offering an emulated environment for mainframe applications, it is reducing risk and delivering the best possible performance and reliability. But this is a load of rubbish. Think about it from the point of view of the mainframe user that has decided to move away from the mainframe – in this case to a Microsoft environment. This is a big step, and the company concerned must be pretty damn sure this is what it wants to do. It has obviously decided that the Microsoft environment is where it wants to be, and as such surely this will include moving to a Microsoft skills set, Microsoft products and tools – database, security, and all the rest. So why settle for an emulation option?

The point Micro Focus has missed is that emulation is a way of propagating the old. After all, it originally stemmed from terminal emulation, where the object was to make sure that end users still saw the same environment even when their workstation technology changed. This was very sensible, becuase it focused on the right priority – don’t force the end users to have to retrain. But let’s be clear – emulation costs. It provides an extra layer of software, affecting performance and scalability, and puts future development in a straightjacket because it propogates the old way of doing things. However, in this case the cost of retraining end users would far outweight these implications.

But in the situation where a user is moving off the mainframe to a Microsoft world, why would the user want to propogate the old? Yes, the user wants to reuse the investments in application logic and data structure and content, but surely the user wants to get to the destination – not be stuck in purgatory, neither in one place nor the other. Why restrict the power of .NET by forcing the user to operate through an insulating emulation environment? Why hold the user back from moving into the native .NET database system of SQL Server and thereby leveraging  the combined power of the operating system, database and hardware to maximum effect? Why force the user to have to maintain a skills set in the mainframe applications when one of the reasons for moving may well have been to get to a single, available and cheaper one?

Yes, the Micro Focus approach may end up reducing the risk of the porting process itself, since it tries to leave mainframe code unchanged, but that is a long way from reducing the risk of moving from one world to the other. And as for the comments on leaving everything unchanged to ’deliver the highest levels of performance and reliability, that is just laughable. What makes Micro Focus think that the way an application is designed for the mainframe will deliver optimal performance and reliability in a .NET environment? The two environments are completely different with totally unlike characteristics. And when has an emulation layer EVER improved performance/reliability?

I see this ReUZE play as like offering someone drugs. If you’ve decided you want to move off the mainframe to .NET, I have a drug here that will reduce the pain. You will feel better …. honest. But the result is you will be left hooked on the drug, and wont actually get where you want to be. If you have decided this migration is for you, don;t try to cut corners and fall for the drug – do the job properly and focus on the end goal rather than the false appeal of an easy journey. Just Say No.

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

Microsoft’s project Oslo is both interesting and ambitious as a concept and a project.

As a concept, Microsoft is recognising the need for formal modelling – in particular for SOA – and as a project Oslo promises to provide formal modelling capabilities across a range of Microsoft products over the next couple of years. Unfortunately, the announcement also seems to reflect Microsoft’s wish to live in a parallel universe of its own making.  This is unfortunate as such a parallel universe is fundamentally incompatible with SOA – which Oslo seeks to enable.

To focus for a moment on the positives: Oslo must be acknowledged as a major move from a vendor who up to now wouldn’t touch any sort of modelling with a 10 foot pole.  While I certainly don’t believe that model based approaches are perfect, standards such as UML when used appropriately and pragmatically can be very effective in the development process.  Given its previous position as sceptic, Microsoft is in a good position to deliver such a pragmatic and accessible solution and this appeared a first read to be its goal as quoted here:

In the past a very select group of users has used modeling. Microsoft is going to make modeling mainstream for the average developer.

said Martin. [Steven Martin, director of product management for Microsoft's Connected Systems Division]

To a great degree, Mr Martin is right:  Formal modelling tends to be used by only a minority and the learning curve and perception of complexity and cost put most off:  There is definitely an opportunity to make modelling more accessible to less technical and less modelling-aware developers.  However, rather than at least taking UML (the widely used and mature modelling standard) as its starting point, Microsoft has decided to go its own way and thus ignore much experience and knowledge of how to model systems built into this standard.

Furthermore while aiming to be more democratic in its approach, Microsoft also appears to wish to entwine the modelling activity into its own technology stack.  This will inevitably result in a Microsoft only model which in turn will allow its customers to build only Microsoft dominated (if not exclusive) versions of SOA.  Which will be great for that minority of Microsoft exclusive shops and of little use for the rest of the world.

As Oslo is still only at its earliest stage, perhaps Microsoft could reconsider its decision to ignore the standards and the heterogeneous world most of us live in …  please

Ronan

Whether or not Microsoft actually has a SOA strategy is far from clear (in the sense of actually committed to SOA in a strategic way as opposed to covering the bases in sufficient depth to be credible through alliances and product tweaking).

However, its latest announcements around BizTalk seem to have sparked off another wave of attacks from people who are deeply suspicious about its commitment and motives. For instance, Dana Gardener of Interarbor, really lets rip:

“My take is that inside of Microsoft its aggressor A-types are all about dissing SOA and promoting .NET ad nauseam. At the same time the Microserfs and developers must understand the inevitability of SOA for at last a portion of the most advanced and innovative enterprises’ and service providers’ architectures.”

To quickly jump off the fence: I don’t believe that Microsoft is as any way close to being as commited to SOA as most of the other industry majors (IBM, Oracle, Sun, SAP et al). However, this may not be a bad strategy for Microsoft right now. The reasons why this is so are well expressed by The CIO Weblog:

“Microsoft doesn’t have to have an SOA strategy now, anymore than they needed an Internet strategy before Netscape or a search strategy before Google. …A recent IDC research report shows them holding a comfortable lead in the architecture and platform development tools that will be used to build out whatever SOA most companies will bother to develop in the near future. And as frequently been pointed out, here and elsewhere, it’s not so easy to break the inertia that large corporate IT shops generate when they make those initial choices. Microsoft has plenty of time to manuever, and as of yet, little need to do so, clamoring of pundits aside.”

While many would argue that Microsoft’s lack of internet and search strategies significantly damaged the company, it is not an unreasonable argument for SOA if you consider their customer base: The smaller Microsoft only shops aren’t in the first waves of SOA adoption anyway, the larger Microsoft only shops will be bound to use Microsoft tools and finally the large enterprises which are a mix of Microsoft and others (I would suggest these are vast majority of the “the most advanced and innovative enterprises” mentioned above) will use Microsoft tools in their SOA strategy when needed.  Why? Because SOA is an architecture – not a product category: You can get started mostly using exsiting tools.  Therefore, Microsoft are guaranteed to be in the SOA programme frame anyway and so doesn’t need to try “to win” its share of initial projects.

So, are there risks for Microsoft and its customers associated with its take on SOA? Yes, I think there are major risks and these will become apparent over the next 12 to 18 months: Firstly, as customers who mix Microsoft with non-Microsoft get deeper into SOA, they will move beyond relying on existing tools and need more and more tooling designed specifically for SOA.  This tooling is more likely to come from vendors who have a deep SOA commitment. This will risk Microsoft’s share of the pie in the large mixed accounts.

Secondly, as IBM et al create SOA-based solutions for common emerging customer problems (think the next Basel II or Sarbanes-Oxley or CRM), Micosoft will be disadvantaged because the SOA based solutions will be more consistent with the customers’ existing architectural direction (i.e. SOA). This will not only limit their growth in the mixed accounts, it will also limit their ability to enter new large enterprise accounts.

Of course, this is all predicated on SOA remaining a popular and growing architecture … and however unlikely it may seem today to SOA advocates that SOA could hit a wall, this is probably Microsoft’s real bet.

Ronan

Microsoft recently made two SOA related announcements:

The next version of Biztalk will have a SOA veneer (commented on by Joe McKendrik ) and more interestingly Microsoft will lauch a  Software as a Service(SaaS) SOA offering.

I blogged previously about how SaaS itself increases the requirement for integration as multiple SaaS based applications must be integrated together.  This has the potential to derail SaaS initiatives – particularly in smaller organisations without sufficient IT skills and budget to deliver on an integration strategy (SOA based or otherwise).

Microsoft is taking a different angle on the SOA and SaaS story by focusing on cross-department integration and attempting to solve particularly painful aspects of the problem with SaaS offerings that will be called collectively Biztalk Services.  In essence, each service hits a specific integration issue which would otherwise require a potentially large investment in infrastructure.  The first two are:

• Identity: allowing management of users across departments and organisations and
• Connectivity: providing enterprise style message (pub-sub for instance) across the internet with appropriate security – thus making ‘safe’ exposure of a SOA service across multiple organisations.

Their picks of identity and connectivity for the first two services is smart as both are inevitably part of any cross-departmental SOA project.  The strategy is also smart as it neatly leverages where Microsoft is already strong (at the department level and in SMB) and where the SOA skills shortage is hitting hardest.

As such I don’t think it is necessary to look at this announcement through Google-tinted glasses and disagree with Ron Schmelzer of Zapthink who is quoted as saying:

“I think Microsoft is really rethinking a lot of their server infrastructure because Google is a competitive threat,”

Microsoft is not doubt thinking hard about Google but it is only fair to point out that this is not a market where Google is relevant as yet and it is not a new departure for Microsoft or even Biztalk:  Biztalk was originally about internet-based integration as this article from 2000 shows.

Ronan