Gatekeeper 2002
In the late 1990s I started to work on turning many of the software lifecycle problems I had solved into products. This effort was referred to as — QBAL, Quantitative Business Asset Library.
QBAL was a play on the name for the CMMi Process Asset Library (PAL). I had built a custom PAL and Engineering Portal for a client. The PAL was a key tool in helping the client achieve CMM Level 2 certification. I stopped work on the QBAL product in early 2000s, but have never stopped thinking about the problems that are still to be solved, and in recent years have done more research and prototyping.
The same problems exist today and are actually worse, as the amount of data a person has to work with today is significantly greater than in the 90s. Fragmentation in technology has increased complexity significantly.
What is it? A configurable suite of 27 applications used to manage the software development life cycle in software engineering organizations. Based on each departments requirements, the team can choose as little or as much functionality as needed.
Each of the applications are referred to as QBALs. Each team is able to define what information is exported and available to other teams.
I wanted to share with you some of the thinking that went into design and deployment. One of the unique features was that QBAL is meant to be delivered to each team instead of a monolithic centralized installation, I refer to that as vertical automation.
My approach since first working in engineering has been that “monolithic anything” is a potential for inefficiency. Along with that, I believe that each team can best control their own destiny by having their own product life cycle stack.
By designing for a team, the definition of a team could be five people working on a project or an organization of 500 people. This meant there could be centralization where it was required, and independent product lifecycle (PLC) stacks that can be decentralized. For example, QBAL could be configured to represent an independent product lifecycle for a Firmware team and a Web Application team, and could support a distributed instance for each project or centralize all projects on the same instance.
I had been setting up teams in this manner for 10 years before creating the QBAL project. In one instance a team was co-developing a product in Java/C with another company. Both companies were releasing their own proprietary version, while co-developing on common code.
Utilizing the approach that would become QBAL, I created a development and integration SDK that supported each companies proprietary code and environments and also the common code and environments.
Managing change became very predictable, even though a single development and integration SDK supported three different codebases. The mechanisms to develop, integrate, build and test worked across all codebases and adapted to proprietary requirements.
Many problems were solved during this effort. One of the key problems that was solved was how to protect intellectual property and still create an efficient development environment for all stakeholders.
Another problem solved was how to scale an organization’s product lifecycle and infrastructure down to a small team. By scaling down, it became easy to scale out and up. Granularity became core to everything in the organization. Coupled with a process principle that everything must be relocatable resulted in: build, test, publish — anytime, anywhere, anyone.
This allowed each team to tailor the product lifecycle and underlying environments to best support their business model.
qbalsoftware.wordpress.com 
Leave a Reply