The simplest definition and the one I like is the concept of Development teams working directly with Operations teams in an IT organization. However, the tide has changed. The needs and definitions mean different things, depending on the size of an organization. For example, in smaller counties, resources are slim and staffers find themselves playing several roles.
Following the terminology of DevOps, I would define DevBA as Development/Business Analysis. Again, this really only applies to small and medium-size organizations where resources are slim and the duties of Developer and Business Analyst cannot be separated. What this means is Development staff must work directly with vendors and department stakeholders to establish proper business requirements. As always, staff must clarify and define the problem and/or business rules and constraints before finding the right solution. In government, it is easy to establish similar problems across several agencies and jump to conclusions as to what they need before they actually have a need for it.
I have seen a big issue with integrations in small organizations. Often, because of this DevBA theory, developers/analysts find themselves starting and stopping where a specific department begins or ends a workflow or task. However, if you open up your vision and slightly increase the scope, you start to see a bigger picture of how systems can integrate and simplify employee workflows, improving overall return on investment.
This is usually a very touchy area; scope can be difficult to mitigate when analyzing the entire vision. The days of the BRD (Business Requirements Document) and waterfall methodologies are gone now. Agile development is becoming increasingly popular, especially in small organizations where development tasks are iterative, providing faster success rates. Agile frameworks also allow for quicker software changes and redirections, and faster technology breakthroughs provide better and more integrated solutions. Breaking down applications into smaller pieces can solve more problems faster and reduce outages while improving employee workflows.
The risk of rebuilding is far lower since the impact to the environment is lighter. This follows the principle of divide and conquer. The concept also provides for more flexibility in government, where priorities can constantly shift. The expense of agile methodologies and additional overhead of smaller software footprints usually outweighs the wasted cost of older, failed waterfall projects.
I also think this new concept will follow the ideals of DevSecOps, which basically adds security into the mix, but instead we can call it DevBAOps: Development, Business Analysis and Operations.
Operations is still essential to the success of any software solution, from installation to management and troubleshooting. Again, the size of the organization needs to be well understood. In larger agencies — such as within the federal government, for example — there are more opportunities for separation of duties. In these organizations, you will find developers, analysts and project managers all in separate roles. How far you need to go with separation of duties really depends on the agencies’ requirements for vendor applications or in-house development.
