Butting Heads: Why IT and Business Don't Get Along

By Aki Iskandar

It's nothing personal. But it's getting worse.

Published September 2011

Have you ever worked for a company in which the IT department and the business side (that is, non-technical managers and senior staff) actually got along? If you work in IT, the answer will almost inevitably be a resounding "No!" Why is this the case in so many companies that write their own software to support their operations? This article will attempt to answer that question, and briefly explore first steps toward a solution.

The Problem

The tension between the IT and business camps within companies is the result of incompatible life cycles. The Business Life Cycle (BLC), and the Software Development Life Cycle (SDLC) are simply out of sync with each other. While this was not the case a decade ago, it is very much the case today, and it's going to get a lot worse before it gets any better.

For the sake of this discussion, let's begin with working definitions for BLC and SDLC, and an agreement that even companies that are not in the business of selling software still require software to manage their BLC. That is, a company that manufactures, sells, and services widgets will need custom software to support these activities and manage their operations.

• BLC: The period of time during which a company undertakes activities around the development of a product or service offering, from R&D to manufacturing, marketing, and finally to the point in time where its last unit and/or service is shipped and/or delivered. At that point, the company can typically no longer make a sale due to market saturation, product / service obsolescence (planned or not), or other environmental pressures.
• SDLC: Wikipedia defines the software development life cycle as "a structure imposed on the development of a software product." Like the BLC, the SDLC also represents a period of time during which a company undertakes certain activities around the development of a product - in this specific case, a software product. Software methodologies have been created to assist organizations in creating software, including Agile and Waterfall, but in all cases there are typically well-defined start and delivery (or completion) dates.

Note: for the context of this article, the term software product will refer specifically to a product created strictly for internal use by the company, as opposed to a product created for outside sales and distribution.

That Was Then

The key factor in understanding the relationship between BLC and SDLC is their respective durations or time periods, and how these durations have changed over the last thirty years. Figure 1 breaks that thirty-year period into ten-year blocks, and compares the time periods of the BLC and SDLC for creating larger systems (collections of software to support business activities):

• 1981 - 1990: The BLC, on average, was 7 years. The SDLC time period was approximately 3 years. Result: the business is happy because there is no problem getting its software created in time.
• 1991 - 2000: The BLC, on average, was 3 years. The SDLC time period remained roughly the same - 3 years. Result: The business is satisfied - but has noticed that there is little time to rework things if needed.
• 2001 - Present: The BLC has compressed to 18 months, while the SDLC time period has only modestly declined to 2.5 years. Result: The business is completely unsatisfied - in fact, it's downright angry.  It can never get exactly what is needed, at least not affordably.

This is Now

The problem is evident and getting worse. People on the business side are upset because they simply don't trust that IT can deliver the software on time. "You guys take too long to build the software, and when we get it, it has bugs. It's all wrong!" yells the business manager. That mistrust is exacerbated because the business camp can see, or at least has some intuition of, the worsening trend in the disparity between BLC and SDLC, even if they don't really understand it. They do not understand the software business. They only understand how to manufacture and sell their widgets and services.

On the IT side, the situation is equally dismal. "Those managers - they want everything yesterday! Worse, they want their software built inexpensively and quickly, and they want it to be perfect. And they change the requirements every day!" retorts the IT project manager.

Today, business requirements change quickly because the business is faced with shorter and shorter BLC time periods. Global competition, better informed consumers, and other environmental pressures require business to move lightning-fast. Some businesses face the choice between completely reinventing themselves and closing their doors. It doesn't take a lot of business acumen to see this.

What is less evident is the reason the SDLC has not kept pace with the BLC. Technology has certainly evolved at a breathtaking pace. IT departments now have at their disposal Java, C#, Python, and Ruby, software languages that have shortened the time it takes to write code. Pre-packaged frameworks and software libraries have eliminated the need for developers to reinvent the wheel when implementing common tasks. Today's powerful software editors can even write part of the boilerplate code within seconds. And SDLC methodologies, when properly implemented, have the capability of compressing the SDLC time period. So why, with these improvements and power they place in developers' hands, is the SDLC not getting substantially shorter over time?

The reason is simple. Any shrinkage in the SDLC time period that results from advancements in technologies, has been almost fully negated by the increasing complexity of software requirements in today's wildly competitive and rapidly evolving business landscape.

The Path to a Solution

What is the solution? There are no easy answers. But there are first steps down what is surely a long path. One such first step is to implement a good Enterprise Architecture (EA) program. While a solid EA program, in and of itself, cannot solve this issue, EA will allow strides to be made towards curbing the negative effects of the disparity between BLC and SDLC.

Enterprise Architects have the unique advantage of being in a position to look orthogonally across the organization, across departments and silos. From that perspective, it is a little easier to see the tension between the business and IT camps. Only then, when the problem and its scope are clearly visible, can folks from both sides get together to vet a mix of strategic and tactical solutions in an attempt to mitigate the effects of the problem (i.e. incompatible BLC and SDLC life cycles). Make no mistake: this will be a never-ending process that will require a commitment from both sides. EA is a business process and not a technical discipline.

Conclusion

There is no silver bullet for ending the clash between a company's business and IT organizations. The problem is complex and manifests itself in unique ways in different companies. Hopefully, this article will trigger some ideas for workable solutions within your specific environment and team dynamics. Above all, it takes a commitment from the business and IT camps to steadily propel the organization towards the attainment of its goals in a harmonious manner.

Aki Iskandar is an Entrepreneur and software architect. He has worked as a consultant for Microsoft, Compuware, Progressive Insurance, Allstate Insurance, KeyBank, Ernst & Young, Charles Schwab, and most recently served as an enterprise architect at PNC Bank, where he served as a core member of PNC's EA team and Architecture Review Board. His company's web site: www.LambdaSoftware.com