Difference between revisions of "Business-Driven Development (BDD)"
m (→See Also)
m (→See Also)
|Line 29:||Line 29:|
== See Also ==
== See Also ==
Latest revision as of 21:56, 14 July 2021
Business-driven development is a methodology for developing IT solutions that directly satisfy business requirements. This is achieved by adopting a model-driven approach that starts with the business strategy, requirements and goals and then transforms them into an IT solution. The transformation is typically achieved by applying model transformations. Due to the alignment of the business layer and the IT layer, it is possible to propagate changes of the business automatically to the IT systems. This leads to increased flexibility and shorter turnaround times when changing the business and adapting the IT systems. Business-driven development goes further than the simple development of delivered requirements in that the implementing resource seeks to both completely understand the business side during the iterative gathering and implementing of requirements and drives to, once acquiring that information, improve business processes itself during the development of the actual solution.
One of the inherent problems in today’s enterprise software development process is an inability to keep up with the pace at which businesses must change in response to emerging trends. In order for enterprise IT departments to survive, they must align themselves with emerging business demands. IT departments are increasingly being expected to engineer solutions that addresses one or more business process problems, rather than concentrating on creating solutions that are IT-centric. Most IT departments spend a major share of their budget in enhancing and maintaining their existing applications. As the business leapfrogs with the latest process enhancements, the inflexible existing applications may not be capable of honoring the necessary changes. In such a scenario, a need for a new mechanism that aligns the IT department's efforts with business demands and business strategy has emerged. BDD facilitates this via a framework that is well understood, standardized, and can be carried out effectively and repeatedly. The first step is to create a [Business-Process-Modeling|business process model (BPM)] and measure it through [key-performance-indicators-KPIs|key performance indicators (KPI)], [Return-on-Investment-ROI|return on investment (ROI)], or other metrics. Then, the enterprise can use these BPMs as a crucial mechanism to communicate the business requirements to the IT realm.
The Need for Business Drive Development (BDD)
- Companies today need to keep up with the pace at which the competitive market demands new business capabilities. Approximately 80 percent of a company's IT budget is spent either maintaining or enhancing existing applications. These existing applications were not created with flexibility in mind, and hence, while the business is leapfrogging with new and enhanced processes, the IT backbone is incapable of honoring the required changes. Traditional applications and architectures are not able to keep up with business innovation, primarily because the processes are not adaptable to on demand business needs. Business requirements often get transformed into siloed IT projects that cannot work together; reusability between artifacts created for different IT projects is often very low.
- A mechanism needs to be devised by which IT efforts are interlocked with business strategy and requirements through an execution framework that is standardized, well understood, and can be executed repeatedly and successfully. The enterprise might achieve business flexibility through IT by modeling the business processes that collectively define the way the business executes. The first thing to do is model a business process through its constituent process steps.The business and IT can significantly bridge the communication chasm by using well-articulated BPMs that create a link between what the business needs and what IT implements and delivers.
- While the starting step for BBD is the creation of BPMs, the IT solution structure also needs to adapt to using the BPMs as input artifacts to the design and development phases of the software development life cycle. The IT architecture needs to be able to design and implement the process activities as software components or services.
- By using BBD, the enterprise models and provides new business processes (when conceptualized) to the IT department. Analysis of the new process might reveal either that software services might already exist to address the need and the only work effort required is to wire the existing software services to realize the new business process, or it might reveal that the enterprise needs to implement new software services and add them to the IT service portfolio. Similarly, if changes are needed to an existing process, the BPM is revamped to reflect the change and delivered to IT for subsequent technical revision based on which services might need to be enhanced or modified.
- A BDD approach helps increase the agility of the business and also helps prioritize and align IT initiatives with business imperatives. It also indirectly helps in simplifying the process of cost justification for IT budgets within an enterprise.
Principles for Business-Driven Development
The following principles can be used to characterize best practices in the creation, deployment, and evolution of software-intensive systems:
- Adapt the process: Precision and formality evolve from light to heavy over the project lifecycle as uncertainties are resolved. Adapt the process to the size and distribution of the project team, to the complexity of the application, and to the need for compliance. Continuously improve your process.
- Balance competing stakeholder priorities: Define and understand business processes and user needs; prioritize projects and requirements and couple needs with software capabilities; understand what assets you can leverage; and balance user needs and reuse of assets.
- Collaborate across teams: Motivate people to perform at their best. Collaborate cross-functionally across analysts, developers, and testers. Manage evolving artifacts and tasks to enhance collaboration and progress/quality insight with integrated environments. Ensure that business, development, and operations teams work effectively as an integrated whole..
- Demonstrate value iteratively: Adaptive management using an iterative process. Attack major technical, business, and programmatic risks first. Enable feedback by delivering incremental user value in each iteration.
- Elevate the level of abstraction: Reuse existing assets, reduce the amount of human-generated stuff through higher-level tools and languages, and architect for resilience, quality, understandability, and complexity control.
- Focus continuously on quality: Team responsibility for end product. Testing becomes a high priority given continuous integration of demonstrable capabilities. Incrementally build test automation.
- Corporate Strategy
- Business Vision
- Business Mission
- Business Goals
- Business Capability
- Business Strategy