SOA in the Cloud

It's Thursday morning, you're the CEO of a large, publicly traded company, and you just called your executives into the conference room for the exciting news. The board of directors has approved the acquisition of a key competitor, and you're looking for a call-to-action to get everyone planning for the next steps.

You talk to the sales executives about the integration of both sales forces in three months time, and they are excited about the new prospects. You talk to the HR director who is ready to address the change they need to make in two months. You speak to the buildings and maintenance director who can have everyone moved that needs to be moved in three months. Your heart is filled with pride.

However, when you ask the CIO about changing the core business processes to drive the combined companies, the response is much less enthusiastic. "Not sure we can change our IT architecture to accommodate the changes in less than 18 months, and I'm not even sure if that's possible," says the CIO.  "We simply don't have the ability to integrate these systems, nor the capacity. We'll need new systems, a bigger data center..." You get the idea.

As the CEO you can't believe it. While the other departments are able to accommodate the business opportunity in less than five months, IT needs almost two years?

In essence, IT has become the single most visible point of latency when a business needs to change. Thus, the ability to change is limited by IT. In this case, the merger is not economically feasible and the executive team is left scratching their heads. Indeed, they thought IT was about new ways to automate the business, and had no idea how slow they are to react to change.

However, it does not have to be this way.  The survival of many businesses will depend upon the fundamental change in the way we think about and create our IT infrastructure going forward.  That is, if you're willing to admit where you are, and be willing to change.

How Things Got Off-Track
The issues with information technology are best understood by understanding the history of IT over the last 30 years. This would be why things are they way they are. It's almost like speaking at a 12-step program...you're admitting you have a problem, and are willing to look at how you got here.

It's also important that you check your ego at the door. IT folk typically don't like to talk about mistakes made in the past. Indeed, many will defend to the day they die all IT-related decisions that have been made in the past. That's really not the point. It's not about placing blame, it's about opening up your eye as to what you're currently dealing with, and opening up your mind as to ways it can be fixed.

If there is one issue that comes to mind each and every time we look at the mistakes that IT made in the past, it's managing-by-magazine. This is a term used many times. In essence, those charged with building and managing IT systems often did not look at what's best for the business, but looked at what's most popular at the time. Or, what was being promoted in the popular computer journals as the technology ‘required' to solve all of your problems.

We also have issues with managing-by-inertia, or the failure to do anything just because it's new and unknown. This is the opposite problem of managing-by-magazine, since instead of doing something just because it's popular, we simply sit on our existing IT architecture. Typically this lack of action is rooted around the fear of change, and the risks associated with it.

We had the structured computing revolution, which became the object-oriented computing revolution, which became distributed objects, which became component development, which became ERP, which became CRM, which became service-orientation...you get the idea. Of course, I'm missing a bunch of other technologies that we ‘had to have' including data warehousing, business intelligence, business process management, and the list goes on and on.

Not that these technologies were bad things; most were not. However, they had the effect of distracting those in IT from the core problems of their business, and thus focused more on the productized technology than the needs and requirements of the business. This was due to the fact that analyzing and documenting business requirements was not as fun, and not a resume-enhancing experience. We all want to be relevant.

This focus more on the solution than the problem caused a layering effect within the enterprise architectures. In essence, the architectures grew more complex and cumbersome due to the fact that the popular products of the day were being dragged into the data center, and became another layer of complexity that both increased costs and made the enterprise architecture much too fragile, tightly coupled, and difficult to change.

Today we have IT infrastructures and enterprise architectures that are just too costly to maintain, and difficult-to-impossible to change. As business needs change, including upturns and downturns in the economy, IT is having a harder and harder time adjusting to meet the needs of business. Indeed, as in our example at the beginning of this article, CEOs are finding that IT is typically the latency within the business that causes delays and cost overruns, and IT does not add value to the enterprise as it once did. Remember when IT was the solution and not the problem?

Indeed, IT departments were more productive when they were coding applications in COBOL on mainframes because it required them to be lean and cautious with their use of resources. Today, we have almost too much technology and too many options. We gave IT enough rope to hang themselves, or at least to get their IT architectures in a state that makes them much less valuable to the business.

•   •   •

This article is excerpted from "Cloud Computing and SOA Convergence in your Enterprise...a Step-by-Step Approach." By David S. Linthicum.