Posts Tagged ‘Reuse’

Catch up blog – closing on ESBCON

September 29, 2009

So it has been too long since I found time to write a blog entry. And we have a busy time with the Business Agility Now launch coming hard on the heels of the Smart Work launch. But before I cover some of the key areas these look at I feel I ought to finish off the last 3 tough questions from ESBCON8.

Here are the last 3 questions:

Discuss how your ESB supports SLA, zero downtime and cross-department integration ?

For current ESB users, can you detail popular second-generation projects with quick ROI?

How does your ESB accelerate ‘Design-to-Deployment’ with tooling, widgets, automated integrations, etc?

Lets see whether I can give my thoughts on these in a succinct manner. First what about SLA, downtime and cross-department integration? As ESBs become more pervasive and their presence is assumed, they need to no be seen as a problem – to become a utility…that is how they must be seen – as something to plug into and just work. Of course integration is about more than just the ESB – the connected applications must also be available and so the ESB layer must also be able to tolerate application and other failures well. In IBM solutions we are seeing this extension of always-on availability to include files moving through the ESB layer with the WebSphere MQ File Transfer Edition. This boosts the enterprise nature of the ESB solution, and the ability to exist in a Cloud or cluster environment where needed by the business is also a strong choice factor.

Second question = about second generation ESB projects for quick ROI. This is when an initial investment has been made in an ESB and subsequent integration projects in the business want to leverage this. Of course ideally project selection, from the first step would have been done based on business benefit – addressing the key needs first. A study like an SOA Healthcheck would be a good way to do this. However in terms of picking second projects, anything that reuses some of the investment already made would be a good idea. Once assets are available as services through an ESB they become reusable. This any other part of the business that needs them should be able to reuse them as a part of a composite application, accelerating deployment, reducing cost and boosting ROI. This may drive the selection of projects to enable greater reuse, driving ROI.

Finally how to accelerate design to deployment, with widgets, tooling and automation? This is a pretty broad topic to cover – one of the simpler answers would be that for some requirements, customers could deploy our SOA appliance – WebSphere DataPower XI50 as an ESB – this is exceptionally fast to deploy, simplify needing to be plugged in and configured. However other options, to be used with other ESBs, or with the appliance, would include using WebSphere Transformation Extender which can accelerate tricky integration deployments, including by using Industry packs to address key needs. These, and the best practices we can recommend can all really speed your deployment, again increasing ROI.

Reuse, cross charging and the Cloud

July 1, 2009

One of the big topics of discussion at the Gartner SOA event in London last week was, unsurprisingly, Cloud Computing – it is everyone’s favourite hot topic this year. One session by Yefim Natis really focused on some of the implications of this – and before he started I made a couple of notes to myself to test as to whether he would answer them.

The first was whether Cloud could solve the cross-charging issue (I will explain this in a moment) and the second was whether Cloud would present a good opportunity for WebSphere Service Registry and Repository. Both of these issues were items that were nagging at me from listening both to clients in the Vendor showcase and also to other Gartner analysts.

The big one was cross-charging – Massimo Pezzini had addressed this as a critical issue to the future of SOA. There was a conflict of interest for those parts of the business who provided services. For the good of the business they were encouraged to make the business services they provided as reusable and shareable as possible. However then as their reuse grew as the uptake of SOA spread in an organization, who then was responsible for the costs associated with not just the initial work to create a reusable service but also then the increase in traffic as it became a fundamental part of multiple composite applications. The service providing department would become a cost center, faced with ever increasing costs and demands for improved SLAs. This could drive future work to be made highly specialized to avoid this issue, impacting the ability of SOA to really be successful.

Now in IBM we have always been keenly aware of the cross-charging issue, as this has always been important to our mainframe/System z customers. Our products such as WebSphere Message Broker, which functions as a highly capable ESB,  have therefore included capabilities to identify and charge users for their use of the environment. But of course in a Cloud – an elastic shared use environment – it is explicitly designed for resource allocation and tracking the user and use. Yefim in his session then proposed that deploying these shareable services in the Cloud, with its ability to track and charge for use could lead to these service providers being seen as profit centers instead of cost centers. Now being a profit center when providing internal services is one thing – moving money from one pot to another within a business does not a profit make. But combine shareable services in the cloud with a move to more dynamic multi-enterprise B2B, sharing the costs with partners, and some of the investment decisions can make sense, as well as streamlining your business connections and processes. A good thought for the future.

The other question I had was around WebSphere Service Registry and Repository (WSRR). I had talked to quite a number of clients at the show who were deploying, or starting to deploy assets connected to one or other of our ESBs – and they were trying to figure out whether this truly made them more dynamic. Of course it does simplify your connectivity to use an ESB but then are you just swapping one change regimen for another? I got a good response talking to them about using WSRR to hold each service step, and to search for the service location through WSRR rather than defining its location in the ESB flow – this allows for very simple updates and changes to services without any disruption to the running processes and ESB flow.

Now of course when the services are defined as ‘in the cloud’ this is the ultimate requirement for flexibility – they will never have a fixed location or definition  anywhere other than the cloud so use of a registry to store and locate these will be essential, as well as the other facets it provdes such as identifying rogue services and enforcing business policies. This says to me that when we are talking to our clients about using the cloud, we need to be sure to discuss the use of ESBs and also WSRR.

Lots to do. Should be interesting!

The linkage between ESBs and IT asset Modernization

March 24, 2009

Having done webcasts recently on both ESBs and Modernization I have been thinking a lot about how these 2 subjects are related – and how businesses can make the most out of any efforts they put into either of these areas. At the core here is the issue around reuse and simplification. Reuse has stumbled for many years – lack of awareness, Not-Invented-Here and so on. However if there was a desire to reuse assets it was generally prevented by the sheer complexity of the task. The natural progression for many IT systems is to become chaotic. Just keeping them running is a challenge, never mind trying to reuse the same code in different parts of the system.

Businesses have been trying to fix this through architectural practices for many years – Going back 20+ years ago, CICS administrators and developers would deploy Application Owning Regions, File owning Regions, Terminal Owning Regions – all to give some separation between types of function that would then allow specific tasks to be less complex and intertwined. However the move to SOA – which despite the claims of some supporters is not actually that revolutionary or new – merely an architectural template finally supported with well integrated tools covered the lifecycle end-to-end. It is the support of these tools which has been enabling business to measure SOA deployment success, and one of the key parts of the solution is the ESB. True it is not alone – other products such as a registry/repository also play key roles in a true SOA, but the ESB can really be said to enable the SOA runtime to be effective and efficient.

Clearly one of the central abilities provided by the ESB is to simplify the application interfaces of those assets connected to it. This helps through the simplification of those assets and thus promoting both reduced costs for maintainance as well as the promise of easier reuse if possible. By increasing the number of assets connecting through the ESB, this increases the savings and improves the chance for future componentization – thus driving the modernization aspect we first mentioned – by simplifying assets it makes it easier to maintain them and to extend their useful life and value – something all businesses need to focus on today.

This use of ESBs for modernization is not just an end in itself – it can also be a useful platform for other benefits – such as improving asset management and governance, even helping to streamline processes. But we will cover that in another post. The key first step is to promote the widest possible use of the ESB across every part of the business, driving all applications, services and other assets to connect to it.

Does this mean that there must be one single mega-ESB deployed across the business? Have we replaced the tyranny of choice with the tyranny of a single inflexible monolithic layer? Fortunately no. IBM believes that a range of ESBs is required to truly meet the needs of businesses – and has three different ESB offerings which provide common, and in many ways shared capabilities but targeted at different markets and offering different deployment options.

The ESB requirements for integrating a wide range of heterogenous and legacy assets have to be different to those integrating mainly standards based newly developed assets. That’s not to say you couldn’t build a single ESB to do so but for some situations it would be overcomplicated and using a sledge-hammer to crack a nut. So IBM believes in ESBs to address these different sweet-spots – designing them to match the needs and skills.

The ESB choices for IBM are as follows:

WebSphere Enterprise Service Bus
WebSphere Message Broker and
WebSphere DataPower Integration Appliance XI50

WebSphere ESB is ideal for customers who have other solutions on WebSphere Application Server, Portal, or BPM platform. Customers may achieve efficiencies in skills, cost, and time-to-value across middleware products in adding WebSphere ESB to their standards-based IT environment.

On the other hand, for customers whose primary challenge is integrating a wide range of non-standard applications into the standards world, as well as those who make heavy use of WebSphere MQ – they will value the flexibility and depth of capability provided by WebSphere Message Broker.

And for those who value the simple experience of drop-in installation and admin-based configuration, and require security at the message level, network level, and device level, WebSphere DataPower Integration Appliance brings that in an integrated solution.

It is the power and flexibility of these ESBs working individually or together with each other that means that IBM has the most complete and powerful solution set to meet any customer need in the ESB and Messaging space.

There is obviously more to say – as to whether all environments need an ESB, and what contribution to a deployment is made by management and governance tools….but we will save those for another entry.

More on Mainframe Modernization

March 23, 2009

Following on from the Modernization Topic – lets answer a few questions about that area:

Q. >What are the architectural aspects of SOA that scare mainframe professionals, and what are the best ways to overcome those reservations?

A.> An important part of that question is whether SOA – or some aspects of it does scare mainframe professionals. Obviously mainframe professionals tend to believe and work passionately for high quality deliverables and levels of service, with strong controls to ensure this. I think that the issues for most would be around the degree of change involved and how that might impact what the mainframe delivers to the business. SOA, if supported with the right tools can actually deliver strong levels of control and increase the business awareness of ongoing work and transactions. This can help to reassure mainframe professionals, as well as the fact that by including the mainframe in SOA, it can help to further demonstrate the continuing importance of the mainframe to the business.

Q.> How do WebSphere offerings fit in with offerings from IBM-Rational? And, will these work with other toolsets?

A.> The business/IT environment can be highly complex and unique to each organization. Depending on differing priorities and where each asset is in its own lifecycle, there may be different decisions being made as to what the key area to focus on and where to progress the business. In some cases that will require analysis and redevelopment of the application for modernization, based around the Rational tooling, in others you will see a more direct approach using WebSphere integration capabilities, but in many cases – probably most – there will be benefits from using a range of these capabilities over the longer term. This is a way in which IBM Services experts can provide assistance by reviewing your existing infrastructure and suggesting a roadmap as part of their SOA Healthchecks – helping you to identify when to use Rational and when to use WebSphere.

Q.> The key themes of IBM’s SOA initiatives have long been ‘Connectivity’ and ‘Reuse’. These terms would seem to take on new dimensions when talking about Mainframe SOA projects. Briefly summarize how IBM views ‘Connectivity’ and ‘Reuse’ when including mainframe data or logic?

A.> Certainly from an IT perspective Reuse and Connectivity have been and continue to be important issues. The assets one is likely to find on a mainframe tend to be those assets which are extremely valuable and therefore likely to be key in any reuse more widely across the enterprise – and these assets may have been more difficult to reuse historically. Reuse of course is a 2-way practice – information and data is involved more widely across the business which demands a better connectivity implementation – they really are 2 sides of the same coin. And of course with the high quality enterprise data and applications that exist on the mainframe the connectivity infrastructure needs to be capable of delivering very strong and reliable connections. This is what the WebSphere solutions are built on.

Q.> Many Mainframe-SOA projects don’t get done because of 2 main concerns – (1) maintaining integrity and SLAs, and (2) visibility into the transaction flow from mainframe to the outside. Summarize IBM offerings for addressing these concerns.

A.> IBM well understands these concerns. Both WebSphere Application Server and WebSphere MQ, the foundation for all IBM’s runtime offerings are built on an absolutely rock solid transactional implementation, enabling the mainframe assets to be used and reused without the quality of service or the quality of data being impacted negatively – instead it is used to extend these traditional mainframe attributes wider into the business – a positive really rather than a threat.

In today’s economy some long-term projects are being put on hold, or replaced with projects that offer quicker ROI. Does IBM offer templates for a 60 or 90 day Mainframe SOA project?

A.> It is more important than ever to not get bogged down in long term IT projects that do not offer clear benefits to the business, especially benefits that can be seen in the near term. Projects that will have overall benefits to the business are likely to need to be justified by a single project use – and once successful may then be rolled out more widely. For modernization of assets this reduces the scope for tasks and level of effort – driving the focus on fast implementations that show clear benefits. While it is still worthwhile to review which projects can reap the largest benefits using efforts such as the SOA Healthchecks mentioned above, it is likely that once identified initial projects might be found that will see results by selecting WebSphere MQ to simplify connectivity and to service enable application interfaces. Not only is a WebSphere MQ project likely to be easier to cost-justify than a more substantial and involved implementation but it will show rapid benefits with increased reliability, enhanced manageability and simpler application interfaces. Further to this other ‘quick hits’ might be from WebSphere DataPower SOA appliances as they are extremely rapid to configue and deploy, needing little in the way of further work, or another choice could be to put a foundation of Governance in place with WebSphere Service Registry and Repository. By quickly finding and logging existing services assets, both developers and adminstrators can quickly reap benefits in both finding and tracking the use of existing assets, reducing exceptions and increasing the potential for reuse.

Issues around modernizing IT infrastructure and assets

March 10, 2009

As I mentioned on a previous blog entry I have recorded a short webcast on Mainframe Modernization for Idevnews

This will be available later this month, but it is a big subject so I want to cover a number of the issues we touched on in the talk and some we didn’t get time to cover. First let’s look at the issue of services and service-enabling assets. Clearly the momentum seems to be that for most new developments that are to be a part of SOA it seems to be sensible to build these new assets as services rather than monolithic applications. However, given the vast majority of IT assets already exist, and are not going away or being replaced – and are not services – what does this mean for a business looking to move to an SOA?

Well SOA does not have to mean services or web services – SOA is an architectural approach rather than any technology or implementation. In fact that is what IBM tries to encourage –  to extend and expand a customer’s SOA goals to include systems which are not – and may never be subject to any reprogramming or redevelopment to change them to services assets. I don’t think there are any customers out there who are 100% SOA – there may never be.

SOA is still a good idea, and businesses seem to sometimes think that becoming service-enabled is the goal – this is wrong. Trying to improve the business by aligning IT with the business through an SOA approach is I think what businesses should be trying to do – that should help them to address the changing needs in this economy.

Now becoming more service enabled – either through modernizing assets directly – the Rational software approach, or by modernizing the infrastructure more than the assets – the WebSphere approach, can help get to this improvement – but just service enablement itself shouldn’t be the goal.

Now there are some people in business who see modernization of IT assets – and therefore reuse – are by some standards dull and the very opposite of innovation and exciting activities – but here’s the thing….think of existing assets as food leftovers in the fridge…..just eating leftovers can be unexciting, but the driver in SOA and modernizing and reusing assets is to use assets in combination with other assets. In the same way combining a few leftovers together can create a wonderful new meal. So service-enablement of assets themselves can be one way to further SOA progress – but the WebSphere approach of simplifying and service-enabling just the interfaces to the assets can be a much faster way to gain modern and reusable access to these assets.

There are of course a number of ways to service-enable these interfaces – WebSphere Message Broker has been able to do this for some time, but also WebSphere MQ can now service-enable interfaces as a part of the WMQ layer – simplifying the task of progress to SOA for business benefits.