According to a Geneca interview study of software projects, 78% of IT professionals feel like the business is out of sync with project requirements. This is pretty much due to the phenomenon observed on the Chinese Whispers Game (a.k.a. Telephone Game): the original idea passes through many different people until it can get released into production. The more people we add in this chain, the higher are chances of message distortion.
The lifecycle of software delivery requires at least the following skills – and enterprises usually have at least one team for each of them: Dev – Developers; Sec – Security; DBA – Database; Ops – Operational; QA – Quality Assurance; Biz – Business Analysts.
All of them execute crucial tasks on the delivery chain, however, this post will focus on three critical teams for software delivery: Biz, Dev, and Ops.
A perfect formula for unsuccessful projects
This scenario usually happens when the Dev team worries only about delivering the application. What technology should they use, architecture, CI/CD, design practice, integration patterns, and so forth. Once the coding is done, they “throw the package” over the wall of confusion (expression born along with DevOps), and the operations team rushes to prepare the provisioning of all the environment required to run the application.
However, when joining the polyglot world of microservices, tasks like deployment and monitoring start being extremely complex, slow, and error-prone for the Ops team.
Every software starts with business requirements. Therefore, let’s add the Business Team (Biz) to this story. After several meetings, the requisites are finally gathered and documented in some trivial office tools like Microsoft Word or Libre Office. The next thing that happens is, the documentation is “thrown over the wall of confusion” so that the devs can read, understand and start spilling code out.
Follow these steps and the company may not survive for too long: customers will have an extremely low response from the organization about their feedbacks; internal teams may misunderstand each other; delivery of new features and bug fixes takes too long; it will be hard to know details about the production software since monitoring will be impacted; each new release will be critical, will require scheduling and needs the presence of each involved person – consequently, fewer releases will happen.
“The product price should be $1.000,00 but it is published as 10,00. Fix this as soon as possible!”, says a stakeholder after noticing a critical business error in the online application. This would be the start of a chaotic rush for the fix and release of this critical error into production.
DevOps: enabling internal I.T. communication
To change the scenario mentioned previously, DevOps culture is being vastly adopted by IT Teams. DevOps is a culture where the wall of confusion between the Dev and the Ops team is shattered, and the work and communication can flow gently and quickly. In this case, a wall of confusion is removed and Dev and Ops teams work in a collaborative way.
DevOps culture will enable automation that starts with code commit and ends up with a production release.
Docker containers are not required but, among other benefits, they shorten the learning curve from the Ops team when handling polyglot applications. It is also proved by companies who use this culture that:
- Increased monitoring quality allows quicker response time and recovery from errors or services failures;
- The capability of performing numerous (and quick) deploys enables frequent releases of new features, supporting agile methods;
- Bugfixes and unplanned work require less time to be released, which increases customers satisfaction.
These, among other benefits, help I.T. faster delivery of reliable software. Although, they do not guarantee that business requirements are delivered exactly as needed with attending to the expected time to market.
BizDevOps: enabling communication between Biz and Tech
Distinguished business value flows naturally from the software which helps to raise customers’ happiness and helps the organization to achieve objectives faster than competitors. By performing DevOps, the team will be able to deliver applications faster, which consequently will lead to frequent deployments into production environment, and faster error recoveries. However, with DevOps these fixes and improvements still exists due to noise in communication between owners of the logic and the tech team.
This game can be won by taking down the last wall of confusion: the one that exists in between the technology team (DevOps) and the Business (Biz) team.
This methodology removes potential bottlenecks on the development process and will bring business users closer to the development team, and the best part is that it will allow them to create and change rules and processes by themselves. They can communicate and understand each other with the support from model and notation specifications. Biz team can quickly validate if the solution attends to the needs
BizDevOps is a culture brings business, developers and operations people together with a common goal: developing quicker, and solving the right business need.
This methodology removes potential bottlenecks on the development process and will bring business users closer to the development team, and the best part is that it will allow them to develop rules and processes by themselves. They can communicate and understand each other with the support from model and notation specifications. Biz team can quickly validate if the solution attends to the needs
In BizDevOps every business rule or process is now a business asset. It no longer needs to have equivalent description documentation (former requirements documents): it is now a graphical asset, auto documented, that gets converted into code itself and versioned automatically.
The assets will reside within its separate projects and will have its lifecycle. A business asset is now contained into a cloud-native service that can easily fit microservices architectures and can be delivered using continuous integration and continuous deployment cycle.
Business requirements are now executable assets, self-documented, versioned, continuously improved and delivered to final users.
Summing up, how should BizDevOps be: Ops team provides a highly available and well-monitored environment to enable additional team deliveries. Biz team authors and maintain business assets delivered within independent services that should be consumed by the microservices forged and delivered by the Devs team.
Summary
Every developer and architect carries a toolbox full of tools and solutions to solve everyday questions. This section of this blog series brought the opportunity to open the reader’s eyes to a new tool that can be added to this toolbox of solutions: Business Automation.
The origins and history of Business Automation tools were presented inside a bigger picture with the to provide comprehension of its evolution and how it fits hype architecture concepts. Along with it, BizDevOps culture shows how to bring the utilization of these tools into the scene of DevOps culture addressing a problem that no other development methodology solves: bringing down the barriers in between Business and Technology teams.
In the next posts, we will begin by learning how to identify the organization’s business automation maturity to understand the next steps on your journey and we will take a look at the digital transformation journey driven by process-and rules-driven apps.
This blog post is part of the first section of the jBPM Getting started series: Welcome to a Business Automation era.
Keep Kalm 