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.
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 Development, Operations, Business Strategy, People 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.
- We promote trust, close collaboration and fast-fail. Most importantly we focus on flow and pull throughout an organization.
- Operational requirements are explicitly covered by non-functional requirements when examining Architectural Profiles.
Environments and automation
- We strongly recommend automation of environments, build and deployment
Cloud computing refers to computing resources provided as a service over a network
- 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
- 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
- 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
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 are a configuration of storage, processing and computing resources used to execute a finished product.
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 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.
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 Requirements, Changes, Bugs 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.
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.