Operations refers to the services and service management provided to the Software Development business and/or its customers. Operations includes services such as environment provisioning, networking, support, asset management, service management, estate management etc.

There are many definitions of “IT Operations” available, in Holistic Software Development we view Operations as providing the common services needed by a business to support its execution of primary business functions (Business User Environments), and specifically common services and processes that are needed to execute the software portfolio, programmes and projects. Operations are an integral part of HSD, considered throughout the lifecycle with services tightly bound to the Definitions of Done.

Operations can’t be considered as an afterthought since the available environments, services and tools will significantly affect both the architecture of Products as well as how quickly development teams can build and react to change.
Operations is a critical enabler to good software development, deployment and execution.


The term “DevOps” refers to tight integration between the Software Development and Operations parts of an organization.

Holistic Software Development fully embraces close collaboration and a holistic approach to developing systems that involves all stakeholders, including developers and operations. As such HSD is a DevOps process however we do not treat Development and Operations as separate parts of an organization – instead we address the entirety of the Software Development Business that includes DevelopmentOperationsBusiness StrategyPeople issues, Quality Assurance, Portfolio Management etc.

The purpose behind the DevOps movement is to ensure that Operations stakeholders are engaged throughout a software development lifecycle so that operational requirements (especially  Non-functional requirements) are included properly. In line with this idea Operations stakeholders, and Operational constraints, must be included in top level requirements and well represented throughout development activity. Operations work, like testing, happens throughout the software lifecycle, not afterwards. Operational stakeholders are involved in the Portfolio Build/Selection practice to ensure that the impact of new product development or maintenance decisions on current Operational positions, and Enterprise Architecture, are understood. Significant changes to current Operational positions are raised as Portfolio Requests so they can be properly costed and scoped.

Work aligned to the principles of HSD must by definition include addressing the needs of all stakeholders from any part of the business. If a divide exists between parts of the business, then the dysfunctional relationship (an example of Conway’s Law) needs addressing rather than process and tooling being introduced. Processes and Tools are helpful to gain agreement on a common approach and automate ways of working but not to solve dysfunctional relationships.

Since HSD promotes regular builds and releases in either iterative/agile or continuous flow models Operations stakeholders must be involved early and often in software development product delivery as a product is likely to be delivered frequently, or even continuously, and so will need transitioning activities performed repeatedly. We recommend treating transition to live environments as a top level Integration Stream and automating transition where possible.

There are 3 aspects to DevOps in HSD:


Cloud computing refers to computing resources provided as a service over a network
Although cloud computing can sometimes be confusing, simplistically replacing the word “cloud” with the word “network” tends to help make sense of any sentence about Cloud computing. Cloud computing involves getting access to (often virtualized) compute, storage, network infrastructure.
Cloud computing offers development teams a number of benefits:
  • Dynamic provisioning of services enabling experimentation, clean environments for testing and deployment
  • Deterministic, rules based environments
  • On-demand infrastructure – no more waiting 6 months for a dev server
  • Automation of build, configuration, deployment, scaling and support
Cloud computing also offers organizations a number of benefits:
  • Development cycles are significantly sped up making the organization more responsive to change and disruption
  • Virtualized use of utility physical resources is often more efficient
  • Infrastructure is fully understood and asset managed
  • “Shadow-IT” effectively disappears
Organizations can build local, private clouds on their own infrastructure or use public cloud providers. Public cloud offers a further set of advantages in that:
  • Hosting, compute and storage are cheaper than on-premises costs
  • 2nd order costs around power, cooling, site safety, security, resilience, space are all out-sourced
  • Hardware refresh budgets and technology research budgets are higher with market leading large cloud providers (e.g. Amazon, Microsoft, Google) than most organizations
We recommend that organizations trial use of public cloud services for Infrastructure-as-a-Service. Building private clouds is unlikely to be a wise strategic move.


Infrastructure-as-a-Service (IaaS) involves providing computing and storage capability in an on-demand virtualized environment. Teams can create servers, compute nodes, storage nodes, networks and other environments through APIs (and usually GUIs).
Private IaaS and Public IaaS enable the ability to create environments (such as a server configuration) deterministically, based on rules. This means that environment creation becomes predictable, and testable, rather than a variable unknown.
IaaS services must be API based to allow development teams to incorporate distribution, load balancing, resilience, fail-over and configuration into the development and build process. Because of the necessary speed, amount of change and quality advantages IaaS provisioning, configuration and tear-down should be automated.
IaaS is sometimes characterized as treating servers as cattle, not pets. They tend not to have special names and designated purposes anymore. Servers are treated as utilities, if one goes wrong we simply turn it off and stand up a new server, with the exact same configuration, in its place – in real-time.
Good IaaS underpins agile and interactive development and is especially useful for very large scale development (e.g. Big Data Analytics) or high complexity software where ephemeral or dynamic infrastructure may be needed.
IaaS is currently best provided by Public Cloud providers rather than built on premises.


Platform as a Service (PaaS) is a step on from Infrastructure-as-a-Service as it a configured environment to build software and services over the network.
PaaS allows developers to create applications based on tools provided by the service. Platforms are made from already set up features, packages and configuration ranging from Operating Systems, execution environments, server management software, design and development tools, hosting tools etc.
Platforms can build on basic infrastructure to create development, test, integration and deployment environments. As environments become more rules based and API driven it becomes possible to wrap up an environment (virtualized hardware, configuration and software) into a single package and simply move it from place to place. This “Containerization” means that as well as considering the progressing of changes, or systems through the levels of Done we can also progress environments, or even networks of environments, through these levels of Done.
PaaS involves taking the grunt work out of development by providing, ideally portable, well configured servers, development and deployment environments that are already hooked up to Enterprise Architecture Mechanisms such as authentication, logging, security, asset management etc.


An overly constrained set of Environments, with formal change management, is a primary barrier to innovation, creativity and motivation in many large complex enterprises. Common practices of out-sourcing Operations without consideration of flexible API based Infrastructure-as-a-Service makes change management expensive and introduces a negative pressure against change, and therefore business agility.

We recommend control is exerted for information management, asset management and security management but not over basic usage and customization of tools and environments. If an organization cannot trust its people to use the IT effectively and non-destructively it is employing the wrong people. Environments might be provided internally by an internal team, an integrated supplier, a private cloud or from public cloud services.

Internal, user facing, environments are typically networked client devices (laptops, desktops, tablets, phones etc.) combined with internal business services such as social business software (instant messaging, email, blogs, wikis, collaboration tools, phones etc.) and external service integration (internet access, etc.). Management services environment such as provisioning, asset management, security management including patching and support are usually integrated in larger organizations.

In our experience different teams need different numbers and types of environments, and so a flexible form of environment provision is almost always needed. Small and large organizations can make use of cloud services to provide flexibility while keeping costs low and yet manageability and security high.

Configuration Management Strategy, Integration Streams and Architecture will all impact the types of environments a team will need. Because the H-Model provides a congruent mapping of streams, to levels of done and environments we start with the following environments:

User Environments

User Environments are a configuration of storage, processing and computing resources used to execute a finished product.

Test Environments

Test Environments are a configuration of storage, processing and computing resources used to test a product.

Continuous Integration Environments

Continuous Integration Environments are a configuration of storage, processing and computing resources used to automatically integrate a product, automating production of Team Builds including some quality assurance activities.

Development Environments

Development Environments are a configuration of storage, processing and computing resources used to provide developers with a workspace and software development tools.


Process Specialist: Tools are just the things you use to do the process; the value is in the process. Let’s do a process first roll out.

Tools Specialist: Tools are the things people actually use. Process is academic and is constrained by the tool features anyway. Let’s do a tools based roll out.

In Holistic Software Development the real value is not in the tools or the process but in the people. Process and tools are something that you add if the people need them.

Tools can be a catalyst for process which can help people be more productive by being a source of common agreement on ways of interacting and a library of practices to choose from but the real value in knowledge work comes from people working together. To that end we recommend that communities of specialists choose the toolsets that will help them (potentially democratically), not those that manage budgets.

We’ve noticed a general trend towards developers seeking open-source and internet based tools which are often very cheap (if not free). Executive management, on the other hand, is the driver for expensive tools packages from large vendors. Give the developers what they need and want, it’s cheaper and better than swallowing a large vendor sales pitch.

Development Tools
We recommend starting with minimal tooling focused on development environments such as IDEs, source version control tools, unit testing and build tools. The choice of these tools will be based on the technology used by the team and Enterprise Architecture constraints, however, we recommend that developers are able to install development tools and control their environments without friction.
We recommend settling on a single source code management solution rather than having several, unless niche technology constraints make that impossible. Git has become the de facto standard and so most organizations would do well to standardize on git, although a range of git servers are available.
Developers working productively is the source of Business Value generation for Software focused businesses. Slowing developers down causes system inefficiency and damages morale.
Collaboration Tools

When working across teams or across physical areas (even in the same building) we recommend use of development collaboration tools and business collaboration tools.

Development collaboration tools such as work item trackers, (agile) planning tools etc. can be useful to provide a record of items such as RequirementsChangesBugs etc. and the links between them. Although often the best tool for this information is a whiteboard and some sticky notes, that solution isn’t very scalable. If a team is entirely self-contained and collocated, then a physical work item tracking mechanism such as a planning wall or board might be more appropriate.

Teams benefit from a single work-item tracking tool so that they can send each other bugs, changes, requirements and other items. A single tool also allows for links between items and wider collaboration on major problems. Avoid tracking work items for reporting purposes, track them for internal team workflow.

Business Collaboration tools such as document/media sharing and editing platforms and social business software (blogs, wikis, instant messaging etc.) help teams communicate both internally and externally and can be extremely valuable in terms of enabling continuous communication between business people,  technical people and wider stakeholders. We recommend that Business Leaders honestly and actively engage with the people in an organization using social business tools, as well as in person, to reach a wide audience and gather the most feedback. Business Collaboration tools, while useful, are no substitute for direct face to face communication however.

Self-Organizing Teams vs. Common tooling

Self-organizing autonomous teams should ideally be able to select their own tooling, picking and choosing the tools that best suit them as time goes by. However, if teams need to widely collaborate and tools need corporate hosting, backup and recovery, common authentication, licenses, support etc. there are numerous business reasons to implement common tooling stack(s) for teams to use rather than have every team making different tooling decisions leading to a fragmented chaotic tool environment.

We recommend that communities of interest (organically formed rather than appointed) are invited to come together to make tooling choices. Those that care can join the discussion and help make the decision. The daily users of a specific set of tools are best placed to make the decisions about which tools to use. In this way communities can self-organize and choose their tools that can then be hosted organizationally.

Very few, if any, complex organizations will get away with a single common tool stack, needs for niche tools such as specialist code editors, visual planning plugins etc. will likely vary from team to team.  We recommend supporting this variation where integration to common workflow / repository / artefact management is possible.

Tools environments will change over time as new and better tools become available and so we recommend that tools implementation is made with an expectation that tool choices will change.

Management Services

There are common Operations service management processes available such as ITIL. We recommend that regardless of which process is used that is kept simple and focused on business value at all times so that measurement driven behavior is avoided – especially regarding the use of Service Level Agreements (SLAs). Operations services, even when out-sourced or cloud based, often represent a significant cost to organizations and are often treated as a fixed cost affecting profit margins or budget for new developments.

Reducing the cost of Operations means more money as profit or for investment in new Business Value.

Classic process approaches to Operations include well known concepts such as 1st and 2nd line support, help desks etc. These processes are often focused on Service Level Agreements to the detriment of business wide flow introducing significant bottlenecks in development processes. We recommend balancing this potential negative with the adoption of Lean Principles throughout the top to bottom business Value Streams. Monitoring Lead and Cycle time across these value streams can help to identify waste and improve systemic efficiency.

Cycle Time is the time it takes to actually do a piece of work. Lead time is the time it takes from the request being raised and the work being completed. Lead Time and Cycle Time are measures common in Lean implementations. Lead Time = Cycle Time + Queue Time.

In Holistic Software Development, Operations environments, technical services (such as email, internal blogging etc.) and management services are reviewed as part of the portfolio in the form of “Business As Usual” Portfolio Requests.This regular review process allows for a downwards cost pressure to be applied and an opportunity to consider opportunities for improvement.

In many organizations the term “Business As Usual” or BAU is used to describe work that is considered necessary for the business to function, including maintenance of legacy systems, infrastructure (see Operations). We recommend qualifying the business value of these BAU items on an annual basis to ensure that continued funding is producing Business Value as part of Continuous Governance. BAU can sometimes become part of the fixed cost base of an organization which means there is less funding for creating new Business Value and research/innovation. In turn this means less profit for commercial organizations and less delivery capability for non-commercial organizations.

Common Services vs. Self-Organizing Teams

Provision of common services and the management processes around those services can sometimes feel at odds with the philosophy of self-organizing teams especially if teams are constrained in their choice of tools, environments and even processes. As mentioned above reasons to constrain team choices from a business perspective may include information management, asset management and security management as well as cost control. However just because some control is necessary does not mean total control is necessary (or efficient).

A balance must be struck between efficiency enhancing flexibility vs. control. That balance will be different for each organization and will likely change over time, especially as industry gets better at building in flexibility into Operations offerings (e.g. cloud provisioning). We recommend transparent explanations for any constraints and being open and accepting of challenges to control decisions as direct feedback from the people involved in a business will be quicker and more accurate than metrics in many cases.

Adoption and Business Change

To gain Business Value from a new product or set of products it must be used effectively by its customers. Product Adoption and Business Change practices integrate a product into the users workflow to get the maximum return on investment.

This article is about adopting a new product or product family into the business workflow or with external customers, not Adoption of Holistic Software Development.