February 13, 2019
Componentization and Reusability: A New Way of Gathering Business Requirements
Share This Post
Reusability is a conundrum many organizations face. Executive are constantly bombarded by vendors, speaking of how componentization is revolutionizing speed-to-market, scalability and cost (sounds like an AWS pitch, doesn’t it?). And yet, when they speak to their own innovation teams, there’s always a reason why something cannot be componentized quickly or reused.
Componentization and reusability are known concepts in the software engineering world that have now permeated business lexicon. In IT lingo, components are well-defined, loosely-coupled reusable pieces of code that represent distinct units of functionality. Software teams often throw out terms like models, APIs, data access objects and plugins as examples of components. The business side gets caught up in the jargon but fails to harness the true power of reusability in their functions. Consequently, they fail to make the right demands from their innovation teams.
A fast-food restaurant is successful not because it makes good burgers, but because it makes and delivers burgers with predictable quality and speed. How do they do this? By allowing customization through the use of components. You can get sauce or no sauce; pickles or no pickles, multigrain bread or white bread (but you cannot get your burger cooked medium-rare). Think of the components as Lego blocks. The blocks are the same, but the way you put them together creates new constructions. While the manufacturing design of the blocks is important, the real skill lies in the hands of the architect who assembles them.
It’s the same with business. When we work with our technology or analytics or process teams to innovate for us, we provide them business requirements ab initio. This is inefficient. We need to start defining these requirements as an assembly of reusable ‘business components’.
What’s a business component? Well, here’s an example. We all spend hours in governance meetings – with our clients, alliance partners. These governance meetings require coordination of participant calendars. Automated calendar scheduling is, therefore, a business component that can be reused in almost every enterprise application (imagine the convenience of an application scheduling, modifying and canceling meetings automatically, based on availability, optional vs mandatory participation and clashes!). And yet most of us still end up using Outlook (off-application) or build scheduling functionality afresh in each innovation project.
Examples of other business components include electronic signatures, secure access controls or executive approval workflows. In the new age of digital transformation, text mining functionalities also qualify (for instance, sentiment analysis of an incoming text feed). These are business needs common to almost any piece of automation built in almost any organizational function.
To be clear, business components could either be pieces of automation functionality (as in an application feature or code) or process functionality (as in a methodology, workflow or procedure).
Most business requirements are obtained through meetings and interviews, and eventually documented as User Requirement Specifications (URS or an equivalent name). Gathering requirements in the form of business components, however, can massively promote reusability within an organization. A recommendation, therefore, is to replace the traditional URS with a Componentized User Requirement Specification (C-URS). A C-URS wouldn’t just specify user requirements. It would (a) check whether a requirement can be componentized for future reuse within the organization; (b) if yes, tweak the specifications accordingly to make them more horizontal; (c) check whether a component already exists within the organization that meets the requirement, with or without some customization.
In short, a C-URS would classify requirements into components that need to be built, components that already exist (with mapping to the relevant piece of code or sub-processes) and non-components. And a Reusability Index (RI) could be calculated, depending on the percentage share of constituent components. The higher the reusability index, the greater the economic value of the innovation project in promoting reusability.
It would be the innovation team’s responsibility to coach the business teams, ask the right questions and ultimately produce the C-URS.
As an obvious corollary, the innovation team must also maintain a business component library, that, in turn, matches each business component to a software or process component, with proper cataloging and search functionality. The component library would be an integral part of the organization’s knowledge management strategy. Building out the initial components would take some effort. But over time the library would get richer. Eventually, the Reusability Index of each new innovation project would start trending higher. Some components would be triggered by reactive business needs, but some components might have to get built proactively, as part of the innovation team’s ongoing charter and budget.
Whenever a fresh innovation project is taken on, the business case for that project must specify (a) how many components are being created and their savings potential for future projects; (b) how many existing components are being reused and the savings because of that reuse. A high Reusability Index would naturally correlate to a strong business case.
Share This Post