By Aki Iskandar
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 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.
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.
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):
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.
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.
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