Calculating PrioritiesBy Scott Mayers | Posted 2011-12-07 Email Print
When Lehman Brothers blew up and the company filed for Chapter 11, the IT organization had to keep functioning.
2. Take a “cascading priorities” approach.
Traditional architecture strategy, even in the design-build environment, tends to put threads of activity into silos. This means that it might not be until the end stages of a major infrastructure project that gaps and conflicts between silos become apparent. This approach should be avoided.
In the LBHI project, each item on the requirements list was interrelated, which meant that the company had to cascade the priorities, mapping out how each one would affect the next and designing the overall architecture to support a “waterfall” of processes and activities across the servers and applications.
At the same time, the company was adapting to a changing financial environment in which business still had to continue as usual. This meant that not only did the technology need to be effectively put in place, but maintaining support mechanisms was imperative, as well. In other words, the design-build process had to be disaster-proof.
As the transition got under way, an on-site, private VMware cloud computing platform delivered speed and flexibility for time-sensitive applications and data, while less critical applications and data were migrated to an off-site location. This hybrid approach maximized the benefits of both solutions: low-latency computing through on-site technology, combined with cost savings from off-site storage. To ensure business resiliency, all locations were also replicated to a disaster recovery site.
3. Measure twice, test infinitely.
Infinite testing might sound expensive—and impossible. But using a testing-oriented approach to IT infrastructure redesign during business-change events is critical.
First of all, the goalposts often move—quickly and far—during a major change. So you’ve got to be sure that the results you are measuring actually hold up when testing against the objectives you are trying to achieve.
Second of all, testing isn’t merely an opportunity to confirm that all is working; it’s also a chance to see what’s not working and how to make changes for the better. In the case of a financial services company, the tolerance for redundancy, recovery and incident-response processes is zero, so constant testing would reveal system failures that put the business at risk of regulatory exposure.
Designing smart systems is just one side of the coin. Testing is the other, and it requires at least as much time and attention.
4. Adopt an adaptive mindset.
Thankfully, most companies don’t have to face the challenges associated with Chapter 11. Companies do, however, face major change events every day: mergers, acquisitions, divestitures, new-technology adoption, new senior leadership ... the list of possible changes is just about endless. Even the smartest companies cannot anticipate every change, but those that adapt best to change will be more successful than those that are entrenched in one—often old—way of doing things.
Just as an organism’s ability to adapt to change is essential to its survival, an organization’s ability to adapt to change is essential for it to maintain its competitive advantage. The cliché “the only constant is change” might sound trite, but it’s an important truth when it comes to IT infrastructure.
With an adaptive mindset, the IT organization can move at the speed of technology while evolving at the speed of business. That is truly forward thinking.
Scott Mayers is a principal and the director for the Integrate and Manage practices at Align, a consulting firm that enables business and IT alignment and delivers solutions for business change and growth.