From Bottleneck IT to Business Agility – How Companies Succeed

As the figure above shows, the problem already exists at the organizational level. Business and IT are linked together. Misunderstandings or ambiguities run through the individual iterations of software development until the correct result is achieved.

A look at the various interfaces between the business analyst’s (business) requirements and their technical implementation shows that software development can be a error-prone process: the more interfaces involved, the more information is lost or interpreted differently.

Decoupling as an Architectural Approach for Business Agility

The solution: A suitable architecture enables decoupling at the organizational level, thereby increasing business agility. What does that mean? The business department should be enabled to take over part of the software development process on its own responsibility – namely the business logic.

Business logic usually changes more often than the process logic or the IT environment and requires a lot of business knowledge. It therefore makes sense to transfer responsibility for business logic to the corresponding domain experts. However, software development is very complex, business-critical and needs to be controlled. So how can business departments be empowered to take on their part in software development? The answer is by abstraction and a suitable toolset.

Business Enablement is already the Reality!

In fact, the business enablement approach has long been a reality: Microsoft Excel or WYSIWYG web content management systems are examples of how abstraction and simple tooling can conceal and help manage complexity – even for non-technical users (with a little technical affinity).

Abstraction Allows Involvement of New User Groups

Other examples include Business Rules Management and Decision Management. The two disciplines rely on a graphic approach to define and implement business logic. Visual models, flow rule diagrams and spreadsheet-like decision tables are easy to understand, even for non-IT users. These models are much more transparent than nested conditions using “If-Then” in some application code. At the same time, these graphical models allow the depiction of very complex relationships, such as risk assessments, credit decisions, compliance checks, etc.

The following illustrations show examples of graphical models that are created (and maintained) through business users and that are already a part of the software development process. Example 1 shows how the business requirements of a credit decision are defined (left), and how its business logic is implemented using a decision table (right).

Example 2 below shows the modeling and definition of a pricing logic with a flow rule approach. Such business rules can become very extensive. However, the visual approach helps users to keep the overview and get along quickly. The project tree on the left supports structuring and organizing the business logic used within a project.

We summarize: Abstraction makes it possible to involve new user groups (in this case business users) in technical tasks that are usually part of the software development process. Although abstraction is often accompanied by limitations in the scope of functions, the business aspects of a system usually do not require the full power of programming languages.

Suitable Toolsets Help with IT Tasks

Business enablement does not mean that business users are taking over core IT tasks that require a lot of expertise. The business users have nothing to do with technical integration, with complex issues such as concurrency, transactions, reliability, etc. Nevertheless, business enablement goes beyond the mere definition of requirements and business logic. However, in order to achieve true decoupling and thus business agility, the toolsets must also support users beyond modeling: namely when testing, monitoring and deploying their business logic.

In practice, the split between business and IT tasks usually varies from project to project. For example, business departments often take on the modeling and testing of “their” business logic, while their IT colleagues oversee quality assurance, deployment, and monitoring.

Conclusion

As IT becomes more and more of a bottleneck and cannot handle many business needs quickly enough, business departments should consider which IT tasks can be done autonomously. Consider some of the following questions to identify such tasks:

• Which aspects of a system or application are business critical?
• Which aspects are changed frequently (more often than the release cycles of the systems)?
• Which aspects require special transparency (e.g. compliance requirements)?
• Does it make sense to maintain these aspects directly in the business department?

With abstraction, a suitable toolset, a little courage and trust, companies can significantly increase business agility. Rare IT professionals can focus on important topics instead of constantly bothering with new business specifications. Business departments gain more freedom and are able to continuously improve their business without relying on IT. That this approach to business agility promises success, we have already seen in hundreds of projects.