Business-Oriented Thinking is Agile Thinking

It is a commonplace to hear "we all have to think like businesspeople" from our clients, employers, and colleagues. For the most part, the software engineering community is in agreement about that. Everyone nods gravely whenever the aphorism is repeated. Oh, yes; of course, we all have to think like businesspeople. So, there's nothing more to say about it, right? Well, maybe.

Despite the raging firestorm of agreement, business-oriented thinking still appears to be the exception among IT professionals. We continue to judge the quality of our work in purely technical terms. We continue to work toward purely technical ideals in everything we do. It is as if we forget that every project we undertake has a purpose, and the purpose may not be served by taking technical refinement of the solution too far.

In pursuit of what?

If you asked a group of IT professionals whether they were interested in achieving "excellence" in their work, their response would be a unanimous and resounding "Yes!" After all, how many of us genuinely aspire to mediocrity? If you then asked for a definition of "excellence," you might hear a variety of different, probably ambiguous, and possibly contradictory answers. Why should that be the case? I think it is the result of two factors.

First, IT professionals are by temperament and by training primarily interested in technical issues. Their concept of "excellence" is narrowly based on the notion of technical excellence. They tend to think of their work as an entity in its own right, without any non-technical context. By extension, they tend to think of their employer as the provider of a playground within which they can explore information technology and hone their skills.

Second, each IT professional is a specialist, to some extent. Each is deeply familiar with a small set of technologies and methods, and each tends to think within the framework of those technologies and methods. Individual definitions of "excellence," then, naturally will be conditioned by the structure and functionality of the familiar set of technologies and methods. Those definitions may or may not apply at a more general level, and may or may not have anything to do with the employer's priorities or goals.

There's nothing wrong with seeking technical excellence. In isolation, for purposes of pure research and development, technical excellence is precisely what we should seek. The problem is that IT professionals tend to think of themselves as engaged in pure research and development at all times. In reality, we spend most of our time working on behalf of someone else; someone who pays the bills for the technology we are using; someone who has hired us to help them achieve their goals.

With that in mind, a pragmatic definition of "excellence" has to include an understanding of our employers' goals. In that context, "excellence" becomes the junction of technical quality with business objectives. A solution that diverges from that junction, even if it diverges in the direction of greater technical quality, will be less desirable than a solution that marks the junction precisely.

Do we need to be reminded of our employers' goals every single day throughout every single project? Do we need to be brought back to reality every time we start to go off on a tangent to explore some interesting technical detail? That would surely be a clumsy way to work. Fortunately, IT professionals have sufficient brainpower on reserve to keep themselves on track, if only they know where the track lies. That, in turn, depends on what sort of company we work for.

What sort of company do we work for?

People apply all sorts of criteria when they analyze and compare companies, depending on why they are doing the analysis or comparison. One can categorize companies in a variety of different ways to gain insight into the factors one deems important.

Sometimes, companies are categorized by economic factors such as market capitalization. This approach can yield a conclusion such as, "ABC Corp is a second-tier player in the Widget sector." Sometimes, companies are categorized by organizational structure or management styles. This approach can yield a conclusion such as, "XYZ Corp has a matrix organizational structure and uses a collaborative approach to decision-making." Different ways of looking at companies may provide insights that are valuable for different purposes.

To understand what a given company expects to gain from its investment in IT, we can look at how different types of companies use IT in their business operations. This is just another way to categorize companies in an industry, or across industries. For our purposes, I suggest we categorize companies as primary, secondary, or tertiary technology companies.

A primary technology company is one whose core business is to develop new technologies; they create technology. They are involved in pure research and development, although the direction of their research may be constrained by market analysis so that they can focus on the most promising areas. Working in such a company, our role may be to identify or help create new markets, develop technologies to serve those markets, or simply to improve an existing technology set. We might work for IBM, Microsoft Corporation, Sun Microsystems, or Sony-Ericsson in that capacity.

A tertiary technology company is one whose core business is something other than technology, but that requires IT support to carry out its business processes; they use technology, but they do not create it. Working in such a company, our role may be to identify, install, customize, and integrate off-the-shelf IT solutions in support of our employer's business operations. We may also develop unique software applications designed to optimize business processes, based on proven, mainstream technologies. We might work for American Express, Russell Clothing, Bank of America, or Pizza Hut in that capacity.

A secondary technology company is one whose business model is to help tertiary technology companies make the best use of technology; they enable technology use, but they do not create new technology. Working in such a company, we might spend some time apprising ourselves of available IT solutions, and visit client locations to help them with IT strategy, product selection, and/or solution design and implementation. We might work for Accenture, EDS, ThoughtWorks, or TietoEnator in that capacity.

The role of IT professionals depends on whether their employer is a primary, secondary, or tertiary technology company. We all tend to think and act like pure researchers. Even as we develop business applications, we spend a great deal of time and effort learning about emerging technologies and experimenting with new tools and new methods. We love to stand around and discuss alternative approaches to a solution, to compare the virtues of different snippets of code at a very detailed level, and to exchange ideas about software development philosophy and methodology.

A certain amount of that sort of thing is probably necessary for anyone who is working on software. Yet, from a business point of view, anything more than a very limited amount of this sort of activity is appropriate only when we are employed by a primary technology company, such as IBM, Sun Microsystems, or Sony-Ericsson.

The business purpose of IT resources in secondary and tertiary technology companies is entirely different from pure technological development. Indeed, it is counterproductive to do pure research and development under the covers of a "typical" IT project in one of those companies. We all do it anyway, because at heart we all want to be working for an IBM, Sun Microsystems, or Sony-Ericsson. That is the reason we entered the profession in the first place, and it has been the focus of most of our training. But to succeed as IT professionals in secondary and tertiary technology companies, we must adopt our employer's business priorities as our own professional priorities.

What is "IT excellence" in a tertiary technology company?

Any company must be mainly concerned with optimizing its core business practices. In a tertiary technology company, the sole purpose of IT resources is to support business operations. Software applications are tools that enable employees to carry out business processes effectively. Anything beyond that, undertaken because of technical interest or for any other purpose, is contrary to IT's mission in the company.

The "perfect" solution is the one that delivers exactly the required business functionality - neither more nor less - at the lowest cost. It is particularly important for us to remember the part about "neither more nor less." In a tertiary technology company, there is no value in spending money on refining a technical solution beyond the level that is necessary to support the stated business requirements. It is simply a waste of money.

In a sense, our role is analogous to that of the facilities personnel who maintain the building. Our job is not to invent a better light bulb, but rather to install lighting fixtures wherever darkness impedes business operations, and to change the standard lightbulbs when they burn out. If we have a burning desire to invent a better light bulb, then we have two choices: We can apply for a job at IBM, Sun Microsystems, Microsoft, or some other primary technology company, or we can join an Open Source project on our own time. But as long as we are working for a tertiary technology company we will never be tasked with inventing a better light bulb.

Is business-oriented thinking compatible with Agile thinking?

One of the key concepts in Agile development is to build the simplest thing that could possibly work. Another is to avoid trying to predict the future, and concentrate on delivering the requirements that are known today. Those ideas are fully consistent with the principle of delivering exactly the required business functionality, neither more nor less.

The Agile approach gives the customer the option to stop development at any time. Once he/she is satisfied that the business need is supported to the extent he/she is willing to pay for, development can be halted. That is not so easy with a Waterfall approach, since the customer does not see the result until the end of the scheduled project. This is another way in which the Agile approach supports business-oriented thinking about IT solutions.

In an Agile project, the customer sees and uses the solution in basic form from the earliest iterations. Based on this early exposure and experience, the customer can refine and clarify the business requirements for the solution. Agile development teams adapt to these changes immediately, resulting in a solution fully tailored to the business' needs. In this way, too, the Agile approach support business-oriented thinking.