Reader small image

You're reading from  Enterprise DevOps for Architects

Product typeBook
Published inNov 2021
Reading LevelBeginner
PublisherPackt
ISBN-139781801812153
Edition1st Edition
Languages
Concepts
Right arrow
Author (1)
Jeroen Mulder
Jeroen Mulder
author image
Jeroen Mulder

Jeroen Mulder is a certified enterprise and security architect, and he works with Fujitsu (Netherlands) as a Principal Business Consultant. Earlier, he was a Sr. Lead Architect, focusing on cloud and cloud native technology, at Fujitsu, and was later promoted to become the Head of Applications and Multi-Cloud Services. Jeroen is interested in the cloud technology, architecture for cloud infrastructure, serverless and container technology, application development, and digital transformation using various DevOps methodologies and tools. He has previously authored “Multi-Cloud Architecture and Governance”, “Enterprise DevOps for Architects”, and “Transforming Healthcare with DevOps4Care”.
Read more about Jeroen Mulder

Right arrow

Chapter 6: Defining Operations in Architecture

The role of operations is changing in enterprises that adopt DevOps. The number one task of operations is to keep services up and running, but in the new digital operating model, a lot of these tasks can and will be automated. Before we start thinking about automating operations, we need to have a clear view of roles, mandates, activities, and domains of operations in the enterprise. This chapter is the guardrail to capturing ops in the enterprise architecture. We will learn how to design architecture for operations and define the digital operating model.

After completing this chapter, you will have learned what the roles and responsibilities are of operations and how this can be addressed in the architecture. We will also see how operations is changing and impacted by the cloud, cloud-native services, and event-driven architectures that use microservices. We will design a digital operating model while making a distinction between...

Understanding operations management

Before we can start defining operations management in an enterprise architecture, including the roles and demarcations between these roles, we need to understand what IT operations include. In this section, we will discuss the definition of IT operations and IT Operations Management (ITOM).

First, why is this important? DevOps has a tendency to focus on development: exploring and building new features and new products. In discussing release management and CI/CD, there's also focus on the development and deployment process. But operations is just as important as development, and the role of IT operations is changing. Not only because of DevOps, but also because of the digital transformation that a lot of enterprises are going through. We will learn more about this in this section.

As a short definition, we can say that IT operations includes all the processes that support hardware and software that are used by the enterprise to fulfill...

Defining operations in an enterprise architecture

IT operations is not a part of the enterprise architecture, meaning that an enterprise architecture doesn't define how an enterprise must perform operations. At best, the operations architecture is part of the technical architecture. In this section, we will elaborate on the components of the enterprise architecture and then study the specifics of the operations architecture.

The enterprise architecture includes the following architectural components:

  • Business architecture: This covers the business functions and the organization of the business, including its operations. From the business architecture, it should be clear how products and services are delivered, as well as what processes are followed for designing, building, and running them. The business architecture starts with the product strategy, which includes describing the products and services that the enterprise delivers.
  • Governance architecture: This defines...

Defining the digital operating demarcation model

The role and position of operations is changing; we saw that in the first section of this chapter. Besides new and evolving technology impacting operations, the most important reason for this is the shift from projects to product-oriented continuous delivery.

What do we mean by this? Most enterprises used to work in projects, typically waterfall type projects. There's a specific end date and the whole project is set out in a timeline with milestones. In DevOps, the focus is on the product: it starts with a Minimal Viable Product, and then the teams keep improving it in short sprints of 2 or 3 weeks.

At the end of the sprint, the product and the deliverables are reviewed. The developers and operations collaborate with these teams. In the traditional model, operations would get a final product and then decide how and when it would be released. The new operating model has to be more agile, adaptive, and embedded in DevOps....

Understanding ops in an event-driven architecture

Let's review the most important task of ops once more: keeping services up and running. To enable this, we have defined a number of processes that help manage systems. Incident and problem management are key processes; that is, in IT4IT terms, detect to correct. The issue is that incident management is almost by default reactive: an issue is detected and actions are triggered to find and fix the issue. In the next phase, typically in problem management, a deeper analysis is done, where solutions are designed to prevent the issue from happening again.

Event management is a component of operations. The challenge in a digital operating model is to orchestrate and automate these events across different IT systems and even platforms. The event-driven architecture addresses this and is actually the starting point of AIOps. We will discuss this in more detail in Chapter 8, Architecting AIOps.

The event-driven architecture was originally...

Planning operations with a maturity model

In this section, we will look at a maturity model for IT operations. Then, we will learn how to apply this to the enterprise and get it to continuous operations. Finally, we'll learn how to get it ready so that it can be implemented by AIOps.

The basic operations maturity model looks as follows:

Figure 6.7 – Operations maturity model

The first level is sometimes referred to as chaotic. Processes are not documented here; operations are merely just firefighting. At this level, it's the tools that define how operations work, instead of having an architecture in place that also defines the toolset. Most enterprises have passed this level.

However, a lot of enterprises are stuck at the second level. This is the committed level, where processes are defined. Incident, problem change, and project management is in place, but the processes are only integrated in a very limited way. There's no...

Summary

In this chapter, we discussed operations management and how this is changing due to digital transformations and the implementation of DevOps. First, we looked at the roles and responsibilities of operations and the different operational service management processes. We also discussed some trends that will impact operations in the near future. The overall conclusion we attained is that the role of ops will change, mainly because of digital transformation and the implementation of agile and DevOps. To become agile, we need operators to be able to focus on their distinctive tasks. We then discussed a demarcation model with product ops and platform ops.

Next, we learned how the architecture will change to become a more event-driven architecture and what the position of ops will be here. Ops will need to have a single pane of glass view, overseeing and even predicting events in the full chain so that proactive measures can be taken. This is what level 3 describes in the operations...

Questions

  1. Name three components that must be part of the technology architecture.
  2. Name the four value streams that IT4IT defines for IT delivery.
  3. An important component of the event-driven architecture is the principle of contained, independent operating services that communicate with each other using APIs. What do we call these services?
  4. On what level in the maturity model would AIOps fit?

Further reading

lock icon
The rest of the chapter is locked
You have been reading a chapter from
Enterprise DevOps for Architects
Published in: Nov 2021Publisher: PacktISBN-13: 9781801812153
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
undefined
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at €14.99/month. Cancel anytime

Author (1)

author image
Jeroen Mulder

Jeroen Mulder is a certified enterprise and security architect, and he works with Fujitsu (Netherlands) as a Principal Business Consultant. Earlier, he was a Sr. Lead Architect, focusing on cloud and cloud native technology, at Fujitsu, and was later promoted to become the Head of Applications and Multi-Cloud Services. Jeroen is interested in the cloud technology, architecture for cloud infrastructure, serverless and container technology, application development, and digital transformation using various DevOps methodologies and tools. He has previously authored “Multi-Cloud Architecture and Governance”, “Enterprise DevOps for Architects”, and “Transforming Healthcare with DevOps4Care”.
Read more about Jeroen Mulder