HP's Application Development & Integration blog

Business Continuity: Let’s be careful out there

2008-08-21T02:50:00Z

Keeping a system up and running in the face of impending disaster is part and parcel of supplying the business with an uninterrupted IT service. Business continuity is an important concept. With IT systems underpinning the core functions of most organisations, the implications of a system suddenly going offline can be both costly and embarrassing. We are probably all too familiar with the groans of frustration when the mail server goes down but imagine the howls of outrage when payroll fails to go through or an important banking service suddenly becomes unavailable.

Some companies simply cannot trade without IT. How much money would Amazon lose for every minute the on-line retailer’s famous storefront is out of action? What would be the affect on a country’s economy if the systems behind the stock exchange took a timeout? Worse still, consider the implications if the compromised system handles the calls for emergency services.

Ensuring business continuity is self-evidently an important consideration when designing any business critical ICT solution. Unfortunately, for most systems, fault-tolerance can often take a back seat during the design process to the functional requirements or the meeting of any performance criteria.

If you are targeting the Java or .NET platform then you may believe fault-tolerance is implicit to any solution. After all, if you have the application server clustered and the database mirrored then what can possibly go wrong?

Well, someone wearing a white HP lab coat might come along and shoot your disk array or blow up one of your servers in a fiery gas explosion. If this scenario sounds unlikely then I suggest you check-out one of the HP promotional videos for fault-tolerant systems.

The video depicts a controlled Disaster Recovery (DR) test in which a primary data centre is blown-up in a controlled gas explosion. The video also has footage of a bullet being fired through a HP disk array.

The guys in the video look like they’ve never had so much fun and I admit to being a little envious of anyone that gets to shoot and blow things up for a living without having to join the armed forces.

In one scene, where the disk array is shot, the director strategically positions a fish tank behind the array. Upon firing the gun, the tank shatters in an explosion of gas, water and possibly fish!

The video with the gas explosion has the system handling high-throughput transactions. When the primary data centre goes boom, all processing is taken over by the secondary. The demonstration used several operating systems: OpenVMS, Microsoft Windows, HP-UX, NonStop and Linux. Each OS failed-over correctly with all services restored within seconds.

This is all impressive stuff from the data centre perspective but how would any business software handle the event?

If we consider a clustered Java or .NET solution, then our fault tolerance consists of distributing the components of the system across nodes in a multi-server environment. A failure of one of the components results in the lose of any uncommitted transactions. We then rely on the middleware to ensure any transactional resources are rolled back, thereby returning the state of any databases, queues or other enterprise resources to their original condition prior to the commencement of the transaction. Obviously, we rely on the infrastructure to replicate the contents of any enterprise resource to a remote DR site.

From the user of the system’s perspective, the transaction would be seen to fail but any session state should failover to another node. Consequently, the user sees an annoying error but their interaction is uninterrupted and they’ll likely have the opportunity to retry the operation that failed.

With this model, data integrity across all enterprise resources (assuming XA transactions are in play) is preserved but we do lose the customer’s data. In fact, we rely on the customer resubmitting the same information in order to complete their initial request. For some scenarios, this level of fault-tolerance doesn’t quite cut the mustard.

When safeguarding the transaction is a priority, it is necessary to look to the services of a fault-tolerant OS. Here, resilience is ingrained into the very fabric of the OS and underlying infrastructure, as opposed to the practice of relying purely on the middleware to clean-up should things go wrong.

With a cluster-capable OS, such as HP NonStop, individual processors keep track of each other’s state through the exchange of “I’m alive” messages. If the community of system processors detects that one of their number has failed, then another node picks up the affected processor’s workload. The mechanism is known as takeover and the intent of the architecture is to allow the transaction to continue uninterrupted in the event of a component failure.

I should point out that this type of technology will not preserve the transaction in the event of the entire site being destroyed, as was shown on the video. Instead, the NonStop redundancy capabilities safeguard against the failure of individual processors in a clustered environment. However, additional technologies, such as Zero Lost Transactions (ZLT) endeavour to preserve any committed transactions in the event of a catastrophic site failure.

This brings us on to the subject of what is an appropriate level of fault-tolerance. Can we leave everything to the middleware or does the solution require a fully clustered OS with a hot disaster-recovery capability?

Deciding on what level of fault tolerance a system requires is a key factor when compiling an effective business continuity plan. Constructing a full understanding of the threats and risks allows us to calculate the cost to the business should a risk present itself. Knowing the cost of a threat makes it possible to design appropriate levels of fault-tolerance into a solution.

Building a practical level of fault-tolerance and disaster-recovery into a system is all about effective risk management, with any mitigation strategies feeding through into the business case for the system.

Here are some other guidelines you may wish to consider when deciding on how best to incorporate fault-tolerance and disaster recovery in to a business system:

· Avoid surprises: The old adage says “what can go wrong will go wrong”. Try to head off potential disasters by being creative and adopting a detail-driven approach to threat management. Run risk assessment workshops as part of the planning process and remember to obtain input from a wide range of people, both technical experts in the system and business stakeholders.

· Adopt a holistic perspective: Don’t constrain your recovery policy to just the core areas of the system, think outside the box. In the world of Web 2.0, we now have external companies providing valuable IT services. What DR plans do your service providers have in place and what are your contingency measures in the event of their service being interrupted?

· Design and build for fault resilience: Enterprise platforms like Java EE offer scalability and failover functions as a standard part of the application server. However, leveraging these capabilities requires adhering to the guidelines for clustered deployments. Ensure you make compliance with clustering standards a part of the development procedures and actively monitor compliance as part of your quality assurance processes.

· Not all disasters are natural: Earthquakes, floods and power-cutting hurricanes are all very well but they are not the only threat. Hardware failures still occur and cyber crime looks to be on the rise. A sense of paranoia is a good trait for anyone developing a disaster-recovery plan.

· Test it: Finally, no business continuity plan is complete until it has been thoroughly tested. We’ve probably all heard the story of the operations team who took backups day in day out, only to find the tapes failed to restore when they were actually needed.

Ultimately, building systems with five nines availability is about good architecture and detailed planning. Think about business continuity from the outset and constantly reassess the threat log.

While you are pondering the DR needs of a current project, take the time to look at a few more of those HP videos. I’ve just caught sight of one where a train smashes into a bunch of servers placed on the track.

How could I ever have thought that hardware was boring!

Alan Monnox, April 2008

Agile development for the mass market with Scrum

2008-08-21T02:29:00Z

Ten years on since Kent Beck encouraged us all to embrace change and most in the IT industry now have a good understanding of the concepts behind the agile movement. However, despite the huge publicity and the wealth of information published on lightweight processes, many would argue that agile methods have still to achieve the status of a mainstream paradigm. For most projects, Royce’s waterfall model, or flavours thereof, still dominates.

I was therefore intrigued to discover that several companies around the region were independently returning to the agile fold. This time around, rather than going down the XP path, all were adopting Scrum. This begs the question as to why Scrum should suddenly be proving so popular?

Scrum emerged back at the start of the agile movement in the mid-nineties and has all the familiar concepts of an agile process, with the method relying on time-boxed iterations to incrementally evolve the solution. Daily meetings, or scrums, plan the day’s activities for the team and help maintain project momentum. The team size on a Scrum development is kept to 5 to 9 members, as this size is seen as optimal for creative work.

The Scrum terminology is undeniably cool. We have thirty-day sprints instead of iterations and the entire Scrum team keeps a close on eye on the burn down chart to monitor progress. Scrum roles are similarly intriguing; the Scrum Master mentors the team while the Product Owner provides business input and administers the product back-log. Beyond these roles we have the pigs, who “have their bacon on the line”, and chickens, who sit on the fringes – wonderful stuff!

So is cool terminology enough to explain the renewed interest in Scrum? Certainly working your way through the burn down chart sounds far more exciting than plain old coding but it is unlikely to be the main reason for Scrum’s upsurge in popularity.

One reason so many companies are jumping on-board with Scrum could be due to the method’s concise nature. Unlike XP, Scrum lacks the detailed practices teams must apply in order to develop software. For example, there is no mention of pair programming, test-driven development or continuous integration in the Scrum world.

Scrum’s apparent lack of meat might sound alarming to some. Indeed, you could argue Scrum is nothing more than a cut-down, low discipline version of XP, made palatable for mainstream consumption by removing the controversial practices. Few of us would argue that practices such as pair programming made many companies distinctly uncomfortable with agile methods.

The argument that Scrum’s success is attributable to the method’s perception as a slimmed-down and sexed up agile process could cause some concern. However, when evaluating Scrum against XP we are not comparing apples with apples. Scrum focuses on the planning and organisation of projects, and unlike XP, the method does not dictate what practices to apply when constructing software. Consequently, Scrum is applicable to a wide variety of projects outside of the software development profession.

Scrum’s concise, consumer-friendly nature is both its strength and Achilles’ heel. To prove successful, teams must understand the limitations of the method and possess the expertise to augment Scrum’s planning and organisational capabilities with the appropriate best practice software engineering techniques.

In the early days of the agile movement, many XP adopters ran into trouble by dropping many of the process’s controversial practices. These teams then failed to instigate alternative disciplines to fill the gaps. A similar danger exists with Scrum in that teams failing to incorporate appropriate development practices run the risk of jeopardising delivery timeframes and software quality.

Plaudits of Scrum will likely react to this criticism by pointing out that Scrum is an empirical method and actively relies on staff bringing their experience and skills to the project. Nevertheless, the fact remains that even with such a consumer friendly agile method as Scrum, project teams must ensure they embrace any new development processes with their eyes wide open.

Alan Monnox, April 2008.

Article on Model Driven Software Development Best Practices

2008-07-01T20:55:00Z

Our team here in HP has been doing a fair amount of work around developing our own model-driven software factory and DSL templates - the ongoing productivity gains relative to manual coding are substantial, as are the improvements in quality and agility. As such I would recommend a recent article by Sven Efftinge, Peter Friese, Jan Köhnlein on InfoQ: Best Practices for Model-Driven Software Development. Recommended reading for all enterprise software development teams out there.

HP Consulting and Integration announces new Application Modernization offerings

2008-04-08T20:43:00Z

HP today announced new Application Modernization capabilities to help customers transform their legacy enterprise applications into an environment that is better aligned to change. HP can help customers to deploy modernized application solutions that maintain their competitive advantage and improve agility.

The new transformation capabilities include:

- HP Modernization 'Factories' - a comprehensive set of processes, methodologies and tools based on HP's proven experience in applications re-hosting and re-engineering

- HP Modernization Showcase Centers – a demonstration environment to help customers with all the phases of application modernization including conceptualization and implementation.

- HP Legacy Application Transformation and Visual Intelligence Tools - rich data visuals based on scientific and technical analysis to help customers analyze the structure and composition of their legacy applications. The tools include:

HP Modernization Profile - Analyzes an application's composition to assist in the selection of areas that may be the key contributors to high cost and low levels of flexibility.
HP Clone Set Analyzer - Identifies duplicate code to avoid repetition of modernization efforts and provide economies of scale to reduce costs.
HP Clone Pattern Analyzer - Reveals hidden patterns of code reuse to help group together similar applications and ensure tasks are not duplicated.

These offerings provide our customers with a simple, efficient way to decompose and transform their legacy applications based upon scientific analysis, while providing a clear cost/benefit analysis to project potential savings and return on investment.

From my own personal experience, core business applications need to be fast, flexible and cost effective and when they aren't, it's just pain, pain, pain throughout the whole organisation. However, with a properly modernized enterprise application, the pain just goes away and frees up an organisation to get on with doing something more valuable. Tools and processes like HP have announced today are essential to "free up" the core knowledge and value within legacy apps, and to manage the risks involved with transformation.

Oracle buys BEA: What’s in it for us?

2008-03-19T23:00:00Z

I started 2008 with the New Year’s resolution to give up alcohol. So far, I’m doing quite well but come April I might just let standards slip and indulge in a few beers. What’s the occasion? Well, as from mid April BEA ceases to exist as an independent company and enters the fold as an Oracle acquisition.

Oracle acquired BEA at the start of 2008 in a move that surprised no one. For years, the speculation has been not if someone will take over BEA but who and when. Having worked with the WebLogic platform since about version 6, I’ll be a little sorry to see the product lose its identity to the Oracle Fusion suite, hence the planned commiseration beer in April.

At this point, all we can do is speculate as to what Oracle has planned for the future of WebLogic. Chances are we’ll see the main product lines continued for several years but really the writing is on the wall and we’ll likely see old favourites such as WebLogic subsumed into Oracle’s middleware stack.

The eventual removal of a big player like BEA from the market means less choice for consumers in the SOA/middleware space. Now less choice is usually a bad thing as it tends to drive up prices and removes the impetus for vendors to innovate. However, in the case of the merger of Oracle and BEA this could prove a positive step for the industry.

The ESB market is still in its infancy and the IT community is spoilt for choice by high-end offerings. All of these tools still have a long way to go before they reach the level of maturity available from traditional component-based platforms. Driving the current crop of SOA tools to full maturity requires not just investment from vendors but for the development community to get behind these technology platforms, and through hard-earned experience, advance them forwards. In short, what’s needed is a critical mass of informed community input that helps shape the future of SOA and the tools that support the service-oriented architectural style. Unfortunately, this build-up of experience has been slow to accumulate due to the fragmentation of the market by so many competing products. In this case, I believe that less is more.

So, whether you’re getting a SOA project up and running or a developer looking to update your C.V., this predicted consolidation of the middleware market should offer benefits. If you’re a project manager then expect to have a larger pool of resources to draw upon. Likewise, if you are a developer then expect to find a broader range of employers wanting your product specific skills.

Nothing personal BEA but someone had to take one for the team.

Alan Monnox, March 2008