You've probably heard of DevOps, or development to operations as an extension to Agile development. BizOps extends that to business to operations, sometimes called BizDevOps, business to development to operations. In some organizations, the term BizOps refers to a cross-functional special team, often of internal consultants, that help in different situations where quick business action and cross organizational scope is required. On the other hand, BizDevOps is a continuous, incremental, data and business driven approach for quickly implementing changes that they are aligned with business goals and strategies, and that what is delivered is measured to ensure that it is achieving the intended outcomes. The best practice is to combine all of this so that the end-to-end spectrum of activities, from triage, to business case, analysis, prioritization, stories, sprints, tests, integration, deployment, measurement and continuous improvement is integrated together. In this article, I'll look at the basic principles and phases of BizOps.

For good reasons, organizations large and small are increasingly adopting development approaches that allow for flexible and emergent requirements, faster development, automation of processes, frequent updates, and operational excellence. Agile development and DevOps are common components of this shift, intended to increase both the speed and quality of releases. In fact, IT organizations are now measured in terms of the frequency of release as a key indication of maturity.

While DevOps can greatly increase the speed and efficiency of development, this often comes at the expense of strategic alignment. At a project level, organizations are deploying software faster, but, are they deploying the right things. While speed is important, it is the right things at the right speed — the “speed of business change” — that is critical to success today. Unfortunately, sometimes those efforts are siloed, where organizations are optimizing for a narrow approach that ultimately suboptimizes the whole or are just heading faster toward more technical debt and redundancy with less enterprise consistency and interoperability. How can we adopt the best aspects of DevOps and also address the challenges?

Some key characteristics of DevOps that contribute to speed are the continuous feedback between stages, faster cycle time supported by small Agile sprints and automation, and metrics that measure the overall success and speed of delivery. A typical (but not exhaustive) set of principles includes:

Taking an economic view
Using Systems Thinking
Preserving options
Advancing incrementally with fast, integrated learning cycles
Managing workflow, cadence and synchronization

BizOps follows these principles and characteristics and enhances them to add an enterprise perspective and extend the cycle to include continuous feedback about business outcomes and continuous, business driven prioritization and planning.

BizOps Continuous Cycle

The figure below illustrates the BizOps continuous cycle.

BizOps-BA_fig1 — Figure 1 – BizOps Continuous Feedback Cycle

Agile Development – Agile development refers to a set of methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. Agile is iterative and incremental, time boxed, test driven, focused on a minimum viable product, based on continuous owner feedback, and measurable.
Continuous Integration – Continuous integration is the continuous process of merging all code to a central repository and validating each merge with the completion a successful compile and build and the running of automated unit tests.
Continuous Testing – Continuous testing is the execution of automated tests against the code base and the various deployment environments. This includes unit tests, static code analysis, security code analysis, integration tests, load and performance tests, all of which are run in an automated continuous testing pipeline.
Continuous Delivery – Continuous delivery is the process of delivering the software and updates to production in smaller, ready to go increments, ensuring that the software can be released at any time. The goal of continuous delivery is to accelerate release cycles and get new code out to production fast.

BizOps takes these key components of Agile and DevOps and extends them to include measurement and strategic and enterprise concerns. The continuous feedback extends to two other important stages:

Continuous Measurement – Continuous measurement is the processes of collecting information about the use, quality, and value delivery of products and services and feeding that back into the loop to achieve continuous learning and improvement and increased value realization. The challenge is not to simply measure the output of products and services, but to measure that they are achieving the business outcomes that are expected. Remember the matra “outcomes not outputs”. Adding continuous measurement into the feedback cycle ensures that an understanding and prioritization of business value is integrated into the Agile development process, and that the definition of “done” includes the instrumentation of software products and services to collect the appropriate metrics.
Continuous Strategy – Continuous strategy is applying a strategic and enterprise context into the selection of project and program activities. This means having an understanding of the enterprise's strategy and context, priorities and dependencies, business and operating models, value proposition and value delivery through products and services. And then, using that understanding and context to guide the selection and priority of project activity.

Intentional Architecture

Of course, there is more to the enterprise context than the items listed above. Enterprises also have a technology strategy and architecture which is critical to the execution of their business strategy – an “intentional architecture” that describes the digital business platform and provides the enabling capabilities for digital transformation of the business and operating models. In addition to the context provided by business capabilities and value streams, the intentional architecture has to be flexible enough to incorporate emergent requirements as products and services are implemented. So, it is developed using the same Agile and DevOps practices as other technology, with one slight twist. As product features are developed, they depend on specific “enabling features” of the intentional architecture to support them. To optimize the overall delivery, the development of these architectural enablers needs to be a few steps ahead of the product and service features that depend on them – in other words, ready when (or before) needed. An important aspect of the continuous strategy stage of BizOps is the identification and planning of the enabling features so that the intentional architecture is always ready to support emerging products and service features.

Architecture can help in a variety of ways, such as providing the enterprise scope that is sometimes missing. Business architectures capabilities help by providing an understanding of what the organization does, and business architecture value streams provide an understanding of what value is and how it is delivered.

The capability map and value streams of business architecture capture the context of the overall enterprise. Since capabilities are unique, non-redundant and non-overlapping, they account for redundancies and overlaps and the inconsistencies that accompany them. Hence, using them for feature planning automatically addresses these thorny enterprise issues. If a business architecture is in place, much of the enterprise business landscape is already known, as well as the intentional architecture needed to support it. This makes incremental planning easier by providing a ready set of features that have been analyzed and vetted within the enterprise business context, the capability gaps that they fill in delivering value, and their dependencies on intentional architecture enablers.

In addition, business architecture aligns well with operational value streams, but unfortunately, some Agile approaches leave it mostly up to the reader to understand what a value stream is, what the important components of it are, and how to develop one. Business architecture provides a consistent and formal method and definition of value streams, so that when they are used to help prioritize activities, they are well formed. The capability to value stream mapping of business architecture clearly identifies what areas need to be implemented or uplifted to improve value. And incidentally, during increment planning, we see a clear correlation between features and Level 3 business capabilities. The measurement aspects of value streams makes sure that organizations are focused on the most important value gaps, and finally, the specific identification of value items as part of a value stream definition identifies specific areas for hypothesis, measurement and testing.

The idea that architecture is somehow incompatible with Agile, DevOps and BizOps is just wrong. Architecture enhances all of these practices. BizOps uses Business Architecture to better understand the business, and to ensure that business outcomes are actually being achieved. But, for this to work, architects have to adopt the ethos of agile and DevOps (I could easily spend another column or two on how to achieve this but suffice it for now that it's possible). The architecture approaches of the past don't work well in these environments. We have to do things differently to fit into the brave new world. But when we do, amazing things can happen.

PDF Version

Bio
Latest Posts

Mike Rosen

Mike Rosen is Chief Scientist at Wilton Consulting Group and a Founding Member of the Business Architecture Guild. Mr. Rosen is also an Adjunct Research Advisor for Business and Enterprise Architecture for IDCs CIO Advisory Practice. He has more than 30 years of technical leadership experience architecting, designing, and developing software applications and products. Currently, he provides expert consulting services in the areas of Enterprise Architecture, Business Architecture and SOA. Previously, Mr. Rosen was CTO at AZORA Technologies and M2VP, Inc., and Chief Enterprise Architect at IONA Technologies, PLC, and Genesis Development Corporation. Mr. Rosen was also a product architect, technical leader, and developer for commercial middleware products from BEA and Digital. His involvement in product development includes Web services, Java, CORBA, COM, messaging, transaction processing, DCE, networking, and operating systems.