Training
Overview
Elicitation of Requirements &  Solution Specification Fundamentals
Techniques for Business Solution Specification
Building a Business Analysis Competency
A Guide to Business Automation Specifications
Practical Approaches to Business Rules
Succeeding with Business Rules, Processes &  Requirements
Practical Business Architecture
Modeling Techniques &  Tools for Business Transformation
The Business Analysis Framework

Business Automation - A Troubled Process

Most organizations struggle with the transition between “business specification” and “automation solution specification”.

This struggle takes several forms:

  • The business is not certain that the business processes they define are exactly what was implemented in the solution.
  • The business finds that it cannot quickly make relatively simple business level changes because IT controls the implementation and release schedules.
  • The IT organization does not believe that the specification delivered by the business is complete because there are many implied changes to embedded knowledge engineering decisions in existing solutions which the business has not reconciled.
  • The IT organization finds that it cannot keep up with the constant pace of change requests although very few of them involve any significant engineering challenge.

Process-centric approaches behave as if there are no existing business knowledge constraints. These constraints are often embedded in existing work practices and automation solutions. By ignoring these constraints these approaches expose organizations to the likelihood that the newly defined processes will depend upon substantial unexamined work to reconcile them with the business knowledge currently embodied in the organization. Further, process-centric approaches typically treat business rules as a detail instead of understanding that the structure of business judgments can be equal to or more complex than the structure of business processes and are also much more likely to change. Embedding business rules into processes introduces constraints to change that can make business processes behave more like a straight-jacket on an organization than an agent of responsiveness.

On the information technology side, existing software development lifecycle methodologies don’t sufficiently address the need for business analysts to retain ownership of certain elements of the business solution domain. In particular, these approaches fail to understand that there is a responsiveness and cost issue associated with removing the ability of business analysts to directly specify and maintain business processes, business rules and the underlying business terms that these depend upon. Yet the typical practice remains that as business specifications move into the automation design arena, IT processes transform the business analyst’s work into an automation design that becomes what the business actually executes. This transformational approach both causes duplication of work as the business analysts work is reinterpreted as well as removes the capability for the business analyst to do direct maintenance of their own business designs.

Historically there hasn’t been an alternative to this transformational approach because business analysts would have to know the language and techniques of IT engineering to directly implement their business specifications. However, with the advent of Business Process Management and Business Rules Management technology the business directed automation solution is now possible. But technology alone is not enough to solve this problem.

In today’s organizations, there is an increased need to address the links and dependencies between the disciplines of implementing business and software change. These include business process transformation, business rules management, requirements analysis and architecture design. But because organizations have integrated a non-business directed approach into their IT project methodology they have locked their business into a process that is wasteful of both time and money.

Introducing "The Business Analysis Framework"

As IT continues to struggle to keep up with business driven change requests in the face of ever increasing pressure for cost reductions, many organizations have been busy evaluating Business Process Management and Business Rules Management technology. This technology comes wrapped in claims that it can allow organizations to respond more quickly to business driven changes. But technology alone is not enough to give the business the ability to take direct control of business specifications. In order to succeed, organizations need a new kind of business specification that can integrate existing business modeling practices with the techniques that integrate with BPM and BRM technologies.

This new kind of specification needs to bridge the current business process modeling work done by business analysts with existing system modeling being done by IT systems analysis groups. In addition, it must be complete so that it can be tested at the business level without the need for the deployment of an IT framework. Most importantly, the business processes, rules, events and entities in the business specification must remain unchanged when deployed into the automation solution. This approach means that the business gains direct control over these specifications because they are the executing specification in the automation solution.

The Business Analysis Framework provides structured techniques for enhancing an organization’s ability to develop requirements—detailed requirements that represent a complete business level specification with defined touch points to IT architecture and design. It enables organizations to create the artifacts and linkages necessary to support a complete business level specification process.

The Business Analysis Framework has evolved over the last 10 years as large organizations have adopted it to address their significant challenges managing business and software change. A proven approach that has been successfully followed by organizations, The Business Analysis Framework provides a formal definition on how to relate business specification elements. It is an essential ingredient that helps an organization develop a comprehensive vision of what a fully mature business-oriented requirements process entails.

By providing a consistent approach to producing complete business specifications, the Business Analysis Framework provides a path for organizations to make dramatic improvements both to their time-to-market delivery of services and products (due to changing markets or competition), and in reducing the costs involved in making routine business changes.

The Business Analysis Framework does this by providing:

  • Clear delineation of the boundaries between business and IT ownership.
  • Reduction in the hidden rework costs of non-aligned business and IT specifications.
  • Elimination of the overhead cost of IT implementing pure business changes, particularly in business rules.
  • Reductions in the business latency inherent in having IT transform business specifications into an IT implementation.
  • Integrated measurement of key business metrics at the process, knowledge and event level.
  • Separation of business process from business rules and business events. The intersection of Business Rules and Business Processes

Because the Business Analysis Framework is a larger framework that subsumes existing practices, it can be implemented in combination with organizations existing methodologies. In addition, its concepts can be adapted to a variety of modeling tools in both the business and IT domains.

The Business Analysis Framework is unqiue because it:

  • Focuses on how to radically reshape an organization’s agility and allow it to create a sustainable competitive advantage.
  • Embraces process orchestration and event-based architectures to support dynamic business behavior.
  • Integrates business rules management into the lifecycle of implementing business and software change.
  • Reduces the hidden rework costs of non-aligned business and IT specifications.

For More Information

To discuss Enterprise Agility's leadership, training and mentoring programs for the Business Analysis Framework concepts and techniques, contact David Heidt at 1-773-227-7110 x106 or at David.Heidt@Enterprise-Agility.com.

For a more in-depth look at Enterprise Agility service offerings visit our web site at www.Enterprise-Agility.com contact an Enterprise Agility Business Development Representative at (773) 227-7110 or email us at team@Enterprise-Agility.com.

Return to top