Friday, March 27, 2009

The Need for Change

"If everything seems under control, you're just not going fast enough."

Mario Andretti—Race Car Driver

Change is a curious word and one that often makes for clich├ęd slogans, political or otherwise. It’s certainly one of the most overused words of the PowerPoint generation, but the fact is that the need for change is real.

Change happens—whether we like it or not. In the end, staying the same in business as in technology is a surefire way to be left behind.

Transformations take place right before our very eyes without our even noticing it. Look at any major modern city and make a quick survey of the kinds of cars you see on the road. Now compare that view with a flashback of the types of cars roaming around in the seventies. Yes, some cars today are pure vintage, thanks to hobbyists, but a look at the landscape today versus twenty or thirty years ago easily demonstrates that car lines have been updated dynamically in a steady process of sun-setting and replacement. Indeed, the median age for cars in the US is about eight years (creeping up to ten years as people are deferring new car purchases due to the recession).

Look at the same city landscape and observe its buildings. If you are in the downtown area, chances are you will find a number of classic buildings, renovated at great expense if the city has gone through downtown revival; decrepit if the city economic center has shifted to the suburbs. IT systems have become more like the buildings than the cars, and frankly, finding renovated IT systems is rare, most legacy IT systems resemble more a decrepit downtown.

Wouldn’t it be ideal if we were able to get to the point where IT systems can be revamped the way car models get renewed every few years? Well, new technology like the Internet and SOA can help here.

The Internet has been a game changer. Its full impact is still undetermined, but it is certainly forcing a closer look at original IT architectures. Legacy systems were designed around less agile service and maintenance models. Back in the days when it was fashionable to hate IBM (before it was fashionable to hate Microsoft and then to hate Google), centralized mainframe environments closely controlled by the glass-house priesthood forced processes that made it difficult to satisfy user demands and presented serviceability bottlenecks.

The need to overcome existing system deficiencies is not new. In fact, addressing ongoing customer demands has been the lifeline of IT organizations for decades. There has always been a need to transform the original systems, and there has always been the desire to replace the legacy with any available emerging technology. However, legacy technologies were not, and are not, easily replaceable, and the irony is that in every successive generation, the new systems were incorporated, but the old system was never actually retired.

Next week I will analyze in more detail the prototypical data center of today. I believe most large corporations have arrived at a common computing system pattern that must be understood if we are to extricate the system from their current complexity.

For now, don't you agree that the picture above is representative of today’s IT legacy systems?



Friday, March 20, 2009

What is IT Transformation?

It’s one thing is to sell to your company the idea that technology can be used to leverage competitive strengths and that the future belongs to those who use modern technology more effectively, and another to precisely define what you mean by IT Transformation. If you fail to explain what IT Transformation is truly about, you could risk ending up with projects that ultimately miss the mark.

For example, while IT Transformation encompasses the investment strategies and tactics needed to leverage modern technologies by refreshing the old with the new, it shouldn’t be confused with Business Process Reengineering (BPR). Yes, BPR may well be either a driver or a consequence of IT transformation, but IT Transformation is not simply an exercise in reengineering. Just replacing something old with something new, such as adding a newer version of a module does not a transformation project make. Even something with a bigger scope such as changing a database vendor, while an important effort, it’s one that's just strictly tactical in nature.

Lastly, transforming basic administrative chores that are similar to those found in millions of other companies is certainly worthy of respect and support, but this type of effort is not IT Transformation. That new ERP system you plan to deploy in your company? You are probably better off hiring an ERP vendor, or a very qualified third party to deal with this transformation. My point is this: not every technology project, regardless of its size, is an IT Transformation project.

What then is an IT transformation project?

IT Transformation is more than mere optimization or modification of engineering components, but is rather a holistic revamp of the existing technology base used to support the company’s mission-critical business. Ironically, IT Transformation is not about changing things for the sake of change, but about better aligning the IT system to the needs of the business. Indeed, based on the results obtained from an April 2000 conference held at MIT, 90% of attendees agreed that matching IT to strategic corporate requirements was the most important factor in a technology strategy; 80% believed that decreasing time to market for new products to be another major factor, and 70% felt managing IT with constrained resources was the driver.[1] This is a key point: IT transformation should ultimately be aligned with the strategic business view.

Because it deals with core business processes (by core, I mean revenue generating), technology transformation will intrinsically be both complex and risky. A failure in introducing this type of technology is not the kind of failure one can sweep under the rug.

IT Transformation deals with substantial core changes to the information systems technology, including the hardware and software of the system, the way the system is architected, and the way the data is structured and accessed. Technology in this definition also includes the algorithms, the IT command and control governance, and the actual and potential functionality supported by the system.

Software projects are hard to execute, and IT Transformation is bound to include a large software element at its core. Multiple studies done on the success rates of software projects reveal numbers that give pause. For example, the Standish Group has found that only about one-sixth of all projects are ever completed on time and on budget (and I suspect that figure includes many less complex projects); that nearly one third of all projects were canceled outright, and well over half were considered "challenged." Also, the typical challenged or canceled project was on average 189 percent over budget, 222 percent behind schedule, and contained only 61 percent of the originally specified features.[2]

In other words, IT transformation is serious business and is reminiscent of those prescription medicine advertisements shown on TV. Any consideration to apply it should come with a similar disclaimer.

Warning: Technology transformation may cause financial hemorrhaging in badly managed companies, resource bloating when done without professional supervision, and abnormal levels of bad media. Other symptoms might include executive insomnia, board irritability, aggression, growth suppression, and Tourette’s syndrome associated with project delays and budgetary overruns. Consult expert advice prior to embracing this solution.

Well, it’s one thing to understand what IT Transformation is all about and another to decide whether we need to take this type of medication.

In the next blog I’ll dive into reasons to undertake a transformation effort. . .

[1] Enterprise Architecture and Next Generation Information Systems—Dimitris N. Chorafas

[2] Major Causes of Software Project Failures--
Lorin J. May. This reference can be found at http://www.stsc.hill.af.mil/crosstalk/1998/07/causes.asp and it goes on to cover reasons for project failures.

Wednesday, March 11, 2009

The time for IT Transformation is now

A while back a politician, whose ideology I didn’t particularly agree with, was found to be spot on about a controversial position. I mumbled a comment about broken watches marking the correct time twice a day. My teenage son Alex, overhearing my snide remark, replied with that characteristic perspective of his, “Not if the watch is digital!”

Information technology is in the midst of a revolutionary revamp. Many, if not all, information systems deployed in the last two decades have become fully depreciated, obtuse, or are too inflexible to respond to new business demands. As a result, legacy systems can’t easily leverage the extraordinary facilities brought forth by emergent technologies such as the Internet.

According to industry watchdogs such as Abeerden Group, Fortune 500 companies, including banks and insurance companies, are sitting in over 500 billion lines of COBOL. As recently as the year 2000, approximately 70% of all mission critical applications were running on legacy technologies, even though, as indicated by Gartner, systems using SOA (Service Oriented Architecture) for mission critical purposes were ramping up from a current 50% to an expected 70% by the year 2010.

What these statistics show is that we are right smack in the middle of an accelerated rate of technology transformation. Computer systems have now been around for over fifty years and every succeeding technology generation has piled up the number of legacy technologies that must be supported; technologies that, under the law of diminishing returns, are becoming less and less capable of meeting the speed of business.

The advent of IT practices and concepts such as Service Oriented Architecture (SOA), Software as a Service (SaaS), and Open Systems, combined with the globalization of the IT workforce have revolutionized the IT landscape. Whereas traditional IT processes were established over several decades to mirror a mainframe-centric view of data processing, new IT approaches can better mirror and support the business.

For many, the turning point where it might make more sense to completely transform the IT systems has been reached, but they may have not yet realized this. The question there is whether it makes sense to undertake a radical transformation or to continue the gradual tactical satisfaction of requirements via incremental upgrades. The answer is not always clear. Radical transformation requires a deep commitment and, frankly, it often represents a significant risk. Gradual improvements, on the other hand, may solve the short-term challenges while digging a bigger hole of continued years of inefficient IT operations.

Compounding the challenge, as I write this, we find ourselves experiencing one of the biggest worldwide financial and economic meltdowns since the grand depression.

There will be, no doubt, those who suggest that this time of economic hardship is not the ideal time to begin work on IT transformation. However, if history teaches us anything, it is that the companies and ventures that emerged most successfully from previous crises were precisely those that continued their investment especially during downturns. These players took advantage of the hidden benefits of a crisis: lower labor costs, new opportunities arising from a transformative macro-economic environment, and that innovated to open new opportunities to compete. It took a truly catastrophic event—a ten mile wide asteroid striking the earth—to wipe out the dinosaurs after an existence of more than two-hundred million years and to open the world to the eventual success of mammals—a class of animals that previously lived a very-contented rodent life but that given the opened possibilities presented by that worldwide catastrophe was nevertheless able to change, adapt, and thrive.

There’s something to this analogy. These are the very times that call out for change.

This Blog will be all about transforming mission-critical IT environments from hard-to- maintain legacy systems to modern systems. I admit to this clear bias (call it an assumption): Sensible IT transformation projects today should follow a Service Oriented Architecture (SOA).

Why? Well, SOA enables technology transformation today in much the same way air travel enabled globalization, or the way Internet enabled on-line shopping. Consider this: actual B2C revenues grew smoothly from 1997 to $70 billion in 2002, even in the midst of the dot-com bubble bursting; by 2004 B2B business was almost $1 trillion from “only” $56 billion in 1999 [1].

If anything, pursuing SOA as part of an IT transformation solution should remove the need for yet-another technology transformation effort such as the one you may have to tackle now or in the future. When done properly, SOA should establish a foundation that can evolve the system so that future transformations can actually live the dream of being able to expand in a more graduated, graceful fashion.

This Blog contains companion material to a book I'm writing, "IT Transformation with SOA—Tips, Techniques & Tribulations."

So here it goes. I hope that you find this notes interesting and useful . I most certainly look forward and welcome your comments!


[1] “The Singularity is Near”—Ray Kurzweil