BPM Voices: How IT can discuss business agility with the business

In this column, Claus Jensen describes how IT can make a difference to the business by adding structure to discussions about business agility. The ability to apply engineering skills to an agile business design is a key differentiator for enterprises challenged by increasing complexity and speed of change. This content is part of the IBM Business Process Management Journal.


Claus Torp Jensen (ctjensen@us.ibm.com), Senior Technical Staff Member, IBM

Claus JensenClaus Torp Jensen is a Senior Technical Staff Member and Chief Architect for SOA-BPM-EA Technical Strategy at IBM in Somers, NY. He leads IBM's SOA Foundation team, working on the convergence of different architectural disciplines. Claus is a member of the WebSphere Foundation Architecture Board.

Prior to joining IBM, Claus had ten years of experience as a Chief Architect and SOA Evangelist.

developerWorks Contributing author

14 December 2011

Also available in Chinese

What IT can offer in designing for business agility

It's common knowledge, for both business and IT alike, that business agility is critical to modern enterprises. Obviously for IT-centric industries, agile delivery of quality IT solutions is a prerequisite for business agility. But is that all IT can do; deliver solutions on time and according to specifications? Many would routinely say yes and let it stay at that, but I'll argue that there are at least two other important value propositions that an engineering mindset can bring to a business that desires higher business agility. IT can:

  • Improve the quality of business requirements in general
  • Teach the business how to think about business agility in a structured fashion

Let's consider each in more detail.

Improving the quality of business requirements

Nothing can slow down IT delivery more than bad requirements. Numerous studies have documented that the most costly defects are requirements defects and that a significant portion of time on most projects is spent fixing requirements defects, time that includes the post launch addition of features that were somehow missed in the first version of the product. Whatever the reason for poor requirements quality, the inevitable consequence is confusion, inefficiency and ultimately mistakes that lead to rework.

The important question to ask is this: Whose responsibility is it to improve the quality of requirements and ensure the precision, context and understanding that is necessary for professional delivery of robust solutions? The easy answer is that it is the business's problem (and fault), but in truth that's making the business a scapegoat for a deficiency in the IT engineering processes. Proper requirements development is a process that IT must take ownership of. If a requirement is imprecise, then questions should be asked until it is not. If the business context if unclear, then it needs to be clarified before a solution design can be finalized. It takes an engineering mindset to effectively decompose complex business problems into actionable requirements, a mindset for which the IT organization is much better equipped than the business organization. In other words, requirements engineering is as important to IT as any software engineering task.

Teaching the business how to think about business agility in a structured fashion

Not only will IT taking responsibility for requirements engineering improve the quality of business requirements, it will also fundamentally change the relationship between business and IT in the direction of a mutual partnership -- a partnership that IT can leverage to introduce a proper language for discussing business agility needs. At the heart of business agility is, in most cases, the ability to detect in a timely fashion situations requiring action, decide which action to take and execute the processes related to the action decided upon.

By introducing the formal notion of situations, decisions and processes into the requirements discussion between business and IT, those discussions are compelled to address key aspects of business agility as an integral and natural part of the conversation -- and in a much more practical fashion than just discussing the vision statement “I want to be more agile.” Agreeing that higher business agility is needed is easy; taking practical action to reach the objective is hard. It's no coincidence that the IT industry increasingly focuses on the combination of Operational Decision Management and Business Process Management as the way to address business operational challenges. IT needs to take the next natural step and inject the principles behind those disciplines in the way requirements in general, and business agility in particular, are being discussed with their business partners.


Discussing business agility with the business has to be based on solid engineering principles in order to convert desired objectives into actionable design. Yet the context for the discussion needs to remain business operations rather than IT solutions. This seeming dichotomy can be resolved by adopting a formalized approach to discussing and implementing operational designs in terms of situations, decisions and processes. This will require a cultural change within the IT organization. In particular, it will require the IT organization to accept intrinsic responsibility for the quality of business requirements and design, as well as the resulting need for business domain knowledge within the IT organization itself. Yet when all is said and done, the effort is well worth it due to accelerated delivery of high-quality, agile business solutions.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Business process management on developerWorks

Zone=Business process management, WebSphere,
ArticleTitle=BPM Voices: How IT can discuss business agility with the business