We are entering a new era: Applications can be configured or assembled from toolkits or frameworks. How will this evolution affect business analysts (BAs) and developers?

A BA typically wears many hats during the development of a new application. His or her duties include planning, scoping, elicitation, requirements, validation, communication, and user acceptance. Often, the basic project management duties of risk management and change management fall into the BA’s basket, as well. Regardless of how comprehensive the scope, the core of the BA’s function is the gathering of requirements — that is, what the new application is supposed to do — communicating those requirements to a technical team that will build software functionality to fulfill those requirements. Clarity, accuracy, and economy are desirable for ensuring consistent, efficient results.

Traditionally, the deliverables for the BA consist of a hefty pile of documents cataloging must- haves, nice-to haves, etc., along with a user interface (UI), use cases, and data flows, where necessary. The technical team, or developers, typically architect an application that delivers the requested functionality, usually with some interim budget- and schedule-dependent prioritization and negotiation. Once the application is coded and tested internally, it is delivered to users and the BA for user acceptance. The deliverable for the developers is code presented in the designed interface that meets the user acceptance test for the functions requested.

The outcome at this point can be highly variable, ranging from routine acceptance to major changes or even abandonment. Obvious variables include the sophistication and expectations of users and the skills and methodology of both the BA and the developer.

This waterfall-type model evolved, because applications have been designed and coded on a custom basis. As long as the application was being created from scratch, users could request what they wanted (within reason). With the introduction of frameworks to business process management application delivery, this model may no longer represent a best practice in every case. Frameworks make available process functions and UI capabilities that allow developers to configure the process from selected templates, leading to significant changes for the BA in two areas: requirements and implementation.

Requirements

Using a frameworks-based approach profoundly changes both the requirements phase and the implementation phase. Once the understanding is reached that an application will not be custom-coded, the concept of user requirements changes. Instead of a bottom-up, fragmented approach in which the BA asks each worker individually for requirements, a top-down approach based on the needs of the process should be used. Using the frameworks appropriate for the process then enables configuration of necessary functionality rather than custom coding.

In other words, the process — not the user — drives the requirements. In any given step, the process will require users to provide certain information, decisions, or actions based on their role in the process. Now, the objective of the BA is to drive the definition of the new process based on overall business goals. The BA needs to work with subject matter experts to ensure that every detail of the process contributes to achieving these goals: each activity, each decision, the logical flow, and the business rules.

Implementation

Whether your company needs to hire a business analyst with traditional skills or to implement one of the new business frameworks, they will need to closely cooperate with developers.

When the new process has been designed, reviewed, and approved by the business decision-makers, the development team can begin work. The team will combine the frameworks platform consisting of process templates and configurable UIs with Web services and other functionality to transform the business model into an execution model, leveraging all the technical configuration capabilities that the platform provides.

This process also means a change for the developers. The requirements are presented to them in the form of business process diagrams, which embody new features driven by the needs of the customers. The BA and the developers work together in a collaborative way to ensure that the technical decisions support the business goals and perform well in a range of environments. In fact, developers can experience increased productivity, as coding now becomes composition and assembly of parts, widgets, and services. In addition, the developers meet users’ and the BA’s needs much more quickly because of the collaborative nature of the modeling, design, and development process.

As frameworks are adapted and extended, additional templates based on lessons learned and best practices are developed and added to the toolset. The developers’ skills are used to provide functionality robust enough to be configured and incorporated in a variety of process models and a range of environments.

In some cases, the change will be met with skepticism, which may be deserved if the composition method is oversold and a pragmatic approach to introducing this change is not observed. Developers need to be assured that the composition framework can effectively handle edge cases and exceptions. Otherwise, every possible complication-from the legitimate to the obscure-will be raised as a reason this model will never work. Visionary information technology organizations understand, though, that this change in software delivery will occur and mature as a much-needed enabler of productivity improvement and business agility, regardless of problems along the way.Software delivery in this model is similar to a change that has occurred in leading manufacturing and service companies — a Lean process that enables just-in-time delivery of software systems as opposed to a long-linked, heavily customized process. Software is produced in framework-defined subassemblies reflecting rigorous quality standards and finally assembled to the customer’s process requirements.

Will this model encompass all software development and delivery? No-certainly not in the immediate future. The matrix shown in Figure 1 may be helpful in describing where these new roles may come to play.

Figure 1: Requirements matrix.

Standard functionality/user-driven requirements

This quadrant of the matrix is the typical commercial off-the-shelf (COTS) procurement in which the BA compiles user requirements into a must-have/nice-to-have checklist with which to evaluate competitive package software applications.

Custom functionality/user-driven requirements

A COTS solution here is not available, and the traditional requirements/development methodology is used. The BA elicits the requirements and compiles functional and business requirements documents from which the developers architect and build the required functionality.

Standard functionality/process-driven requirements

This quadrant of the process is driven by a process model that is relatively predictable in its progression. Although the path of a process instance may fluctuate with variable metadata, the available paths are defined, controlled by explicit rules, and have a set of performance expectations (service level agreements [SLAs]). The BA discovers and understands the process thoroughly enough to create or adapt a process model that the process owners can validate. Once validated, the model is converted to an executable application in collaboration with a developer by assembling the framework UIs, executable templates, and any necessary communication interfaces. Depending on the nature and needs of the project, this task may be performed in iterative steps starting with a proof of concept and progressing to final acceptance.

Custom functionality/process-driven requirements

Increasingly referred to as case management, these applications are driven by a process model that has inputs and outputs, roles and resources, and at least some defined steps. The applications can vary in their path, progress, and duration according to both articulated rules and individual user judgment and initiative. There may not be sufficient data or history to model these processes completely, so the model may incorporate ad hoc collaboration, varied roles and inputs, and a highly variable time line.

This quadrant will likely represent the biggest challenge to the BA. Not only must he or she understand and model the more standardized steps in this process, the BA must also understand the more ambiguous, ad hoc, and creative steps in the process that may include collaboration and/or extended timelines. This understanding is essential in adapting the process functionality to accommodate and support these steps.

BAs will be expected to bring skills to application composition that help to answer questions like:

• * does information need to be shared across organization boundaries? What will the security scheme be?

• * how will metadata affect case visibility?

• * will content be accessed by a public portal?

• * will rules be necessary to define and catalog available expertise available at certain steps?

• * will ad hoc discussions be created and discarded?

• * what are the more defined aspects of the process? What steps are allowed to spawn or call new processes?

* regardless of ambiguities, are there overriding SLAs that must be monitored?

Like the process itself, creative use of the functionality in the application composition framework is necessary to truly support collaboration and access. Fortunately, in many cases, established frameworks like EMC Documentum xCelerated Composition Platform (Documentum xCP) can provide a structure on which to build.

Summary

With the availability of these new frameworks for designing and building process-driven applications, the role of the BA will adapt to engage the agility and efficiency the frameworks offer. Traditional skills will continue to be needed for applications not appropriate for this methodology, but both new skills and a new perspective will be required to truly take advantage of the paradigm shift. To repeat the Lean analogy, it will move away from a lengthy batch methodology requiring handoffs from specialized disciplines toward a process assembled quickly from frameworks components. Like the Lean work cell, this change will require BAs cross-trained and competent in understanding and modeling collaborative processes and creatively applying a robust framework to execute that model. Rather than a handoff of requirements documents, developers will work collaboratively with BAs, adding value to the process model with technical enhancements and tweaks.