Business type 1: The nonsoftware-focused IT organization

Type 1 is a business with a primary purpose other than producing, selling, or operating software. This includes nearly all nontechnology-focused companies, such as banks, restaurants, stores, taxi services, airlines, railroads, media companies, etc. The mission of a nonsoftware company is not technology focused. It may use software as a tool internally to manage sales, marketing, manufacturing, or other business processes, but software is secondary to its primary business.

As such, there are no large application development teams. There is an IT organization, and within that are relatively small (compared to the overall size of the company) development and operations teams, but only a small portion of the company’s resources are invested in IT systems and personnel.

Figure 1-1 illustrates this. The company leadership has bigger things to focus on, leaving IT leadership to manage these small development and operations teams.

Figure 1-1. A nonsoftware-focused company

For these more traditional nonsoftware-based enterprise companies, the IT organization has a purely supportive role. It is primarily operations focused, though it may also have some development capabilities. Tooling and operational processes are the central areas of concern.

Business type 2: The non-SaaS software IT organization

The primary purpose of the second type of business is creating software that it sells to other people or companies. It typically does not operate the software for its customers; instead, the software (which does not require a significant backend SaaS-like application to function) is operated directly by the customer.

Examples of this type of software include popular workplace applications such as Microsoft Word and Adobe Illustrator, as well as games (such as Angry Birds), music applications, and ebook readers. It may also include tools like antivirus software, firewalls, and news aggregators.

A non-SaaS software organization has a software- or engineering-focused mission. These organizations have high-caliber application development teams, but typically do not have a strong operations team. Because the software they produce is operated by customers, not by the company itself, there is no need for a large operational focus.

A generic IT organization provides tools and processes that support the company as a whole. Part of its role is to provide support for the product development teams (as well as sales/marketing, etc.), but it does not directly contribute to product development or operations. Figure 1-2 shows this structure.

Figure 1-2. A non-SaaS software company

Non-SaaS software companies have a strong focus on application development teams, but these are not DevOps teams; they are independent software development teams that produce software that is sold and delivered to customers. The IT organization is small and supports the company as a whole, including the development and operation of tools for internal use; it is separate and isolated from the product development teams.

Business type 3: The SaaS-focused IT organization

The third type of business is a company whose primary purpose is to create a SaaS application or to operate customer software. This includes business-to-business (B2B) companies providing services such as inventory management, financial planning, communications, and sales infrastructure. Examples of SaaS products and companies include Intuit QuickBooks, Slack, Shopify, Mailchimp, and Salesforce.

There are also business-to-consumer (B2C) SaaS companies providing entertainment, retail shopping, and social media services. Examples of B2C SaaS companies include Amazon (retail), Netflix, Facebook, and Twitter.

A highly functional SaaS organization requires a high-caliber application development team and a high-caliber operations team. The two teams must cooperate to succeed. Figure 1-3 shows the typical organizational structure.

Figure 1-3. A SaaS-focused organization

The application development teams in a SaaS company are typically proportionately large groups that require substantial investments in engineering and product management. Each team owns a part of the overall SaaS application and builds, tests, deploys, operates, and maintains only the services it is responsible for. Operations teams provide a smooth operations infrastructure that supports the development teams. The enterprise’s focus is typically primarily on the software development teams. These companies may have separate IT organizations to support business processes, but the application development teams are not part of that organization.

In these high-tech, software-driven companies, the application development teams are a core component of the enterprise. Given its importance, this group reports high in the company’s organizational hierarchy.

Notice that some companies fit into multiple categories. For instance, Microsoft offers SaaS services (Office 365) and non-SaaS software (Microsoft Word and Halo). Amazon offers B2C services (Amazon retail) and B2B services (AWS), along with non-SaaS services (Kindle readers). Additionally, a company like Charles Schwab may offer investment software as a service, yet also focus on general financial services and investments. These enterprises may have different divisions that appear to be separate companies, each structured differently, or they may have a hybrid structure. Keep in mind that the categories discussed here are generalizations.

Development

There is a direct correlation between the amount of focus your company places on software development and the availability of high-quality technical talent and software leadership available to your organization. The best software developers, architects, and software leaders tend to gravitate toward the much more lucrative opportunities in SaaS application development and other software-centric companies.

This means that organizations in which software plays only a secondary role in the mission find it difficult to attract and retain software talent. Often this means the organization as a whole suffers. Yes, there are high-quality, talented developers in these organizations, but they are much harder to locate and hire. This tends to result in there being less innovation and fewer creative solutions to problems in these types of organizations. Rather than being state-of-the-art, the software applications created in such organizations tend to be fairly prosaic, supportive applications.

The caliber of your IT development team is critically important in determining the sophistication of the applications your organization can support, and your organization’s ability to respond to the inevitable increase in complexity that occurs over time.

The result is that organizations in which software is a secondary part of the business rather than the primary focus tend to be more sensitive to the IT complexity dilemma.

Operations

Operations teams, on the other hand, tend to attract high-quality talent based on how central the organization’s operational aspects are to the business focus. This means SaaS companies, which are highly dependent on high-quality operations teams, tend to attract higher-quality operational talent than organizations in which operations are secondary to the goals of the business.

Less attractive o operational talent are nonsoftware companies that require a significant internal software infrastructure to keep the organization running smoothly. This includes organizations such as banks and other financial firms where the software infrastructure is critically important and must stay operational.

Even less attractive to operational talent are companies that produce “boxed” software that is operated on customer computers and systems, rather than in internal operational environments.

This makes sense. SaaS companies rely heavily on highly performant operational environments and invest heavily in these areas. This investment, and the opportunities it produces, attracts top operational engineering talent to these organizations. Organizations that are less operations focused need less investment in this area, and hence don’t attract as much interest.

The traditional operational landscape is changing, however. Many traditional operational capabilities are now handled by outsourced infrastructure, such as SaaS applications and cloud service providers. Additionally, newer tooling and capabilities automate a large portion of basic operational requirements.

Infrastructure as Code (IaC) and Operations as Code (OaC) tools help with this effort, and strive to make operational setup and basic operational responsibilities automated and repeatable. This improves overall operational reliability. Additionally, since scripts and script-like descriptions drive IaC and OaC, these capabilities encourage code as documentation and knowledge sharing of the operational environments involved. Finally, since IaC and OaC generalize the operational aspects of an application into code-like capabilities, they allow the use of standardized and well-understood development processes, such as revision management. Revision management allows tracking and correlating failures to changes, reducing mistakes, increasing security and traceability, and improving overall accountability and performance.

The role of DevOps in the modernization of the enterprise

DevOps is a term in wide use in modern organizations. It describes, in part, the collaboration between development and operations teams within an organization. The intent of DevOps is to break down the traditional barriers that exist between these two groups and encourage collaboration and cooperation, allowing them to work together more effectively and efficiently. This leads to faster problem solving, increased efficiency and responsiveness, and overall higher application quality and availability. DevOps is becoming the norm in modern IT organizations.

In a DevOps organization, individual teams each own some portion of the application. In modern applications, these components are typically services. The individual teams are responsible for the development, testing, deployment, operation, and ongoing support of the services assigned to their care.

Figure 1-4 shows the organizational structure at a software company that uses DevOps principles. As such, it describes the same sort of SaaS company described back in Figure 1-3. The primary difference is that both the development aspects and most of the operational aspects of ownership are assigned to the same team under the engineering and product leadership organization. There is still a very thin operations support organization, but the job of this organization is not to manage the operations of the application; rather, its role is to provide tools and assistance to the product teams that own and operate the individual services.

Merging the responsibility for the development and operations of individual services into a single organization in this way lowers the communication barriers that typically existed in the past between the development and operations teams, improving the organization’s overall performance and reliability.

Figure 1-4. A DevOps-focused software company

Now that we understand more about how modern IT organizations are structured, we can talk about the problem complexity poses in these organizations and how complexity impacts the long-term viability and success of the organization.

How does technical debt grow?

Technical debt can grow naturally and quietly during the normal product development process. Every project that contributes to a product also contributes to its technical debt—even adding a simple feature enhancement. This is illustrated at the top of Figure 1-5: during normal product development, work and outputs are added to the product, and some amount of debt is added to the stack of technical debt.

Sometimes, a project is done in a “quick and dirty” manner, such as when a new feature is added without proper design in order to get it out the door quickly. In these cases, the project adds more debt. Sometimes, the project can even add more technical debt to your application than the amount of real value it provides. This is the case with the example project shown in the middle of Figure 1-5.

Figure 1-5. The flow of technical debt during product development

To keep technical debt from growing without bounds, some effort needs to be added to each project to reduce the technical debt. Keeping your technical debt at a sustainable level requires constant investment in reducing the technical debt over time.

This constant flow of increasing and decreasing technical debt is one of the reasons why it can sneak up on a product. If more debt is regularly added than is reduced from the backlog, the debt will grow, yet the growth may not be noticeable. It’s not until the debt has grown to a point where it starts having a negative impact on your product that you will notice how much has accumulated. At this point, it may be too large to deal with effectively and easily.

Each project can either increase or decrease the technical debt within a system. In a full, high-quality project, the planned work often includes doing all the work necessary, along with working on reducing some amount of related technical debt. When the work is completed, the application’s technical debt is lower than before. This is illustrated in Figure 1-6: the work completed for the project is larger than the project itself, and the extra effort is put toward reducing the size of the technical debt. This is a project that’s dealing with technical debt in a healthy way.

Figure 1-6. A full/complete project has to plan to reduce technical debt

Unfortunately, many projects are much more quick and dirty. They are designed to only complete as much work as is absolutely necessary, leaving the rest to be completed later. In fact, a common project management philosophy involves building a minimum viable product, or MVP—an approach that essentially dictates that you do as little product work as possible to get a functional product out the door.

The result is work that is not completed. More often than not, this increases the overall technical debt of the application. This phenomenon is illustrated in Figure 1-7. Here, the work completed is only part of that required by the project, and it is accompanied by an equal amount of work not done. This additional important work which was not completed ends up increasing the overall technical debt in the project.

Figure 1-7. A quick and dirty project often increases technical debt

Depending on the types of projects undertaken, the amount of technical debt associated with a product will vary over time, sometimes decreasing, sometimes increasing. The more full, high-quality projects that are completed, the lower the overall technical debt will be. The more quick and dirty projects that are used to implement functionality, the higher the resulting technical debt will be.

The negative impact of technical debt

Sometimes, deciding to build a simpler solution now and delaying a longer-term implementation (as depicted in Figure 1-7) is advantageous. It allows you to get a solution out to customers earlier, so the company can start monetizing the change and receive customer input on what they like and do not like, which can be fed into a later, more ambitious solution. This is analogous to the idea that borrowing money is advantageous if you use the money to contribute to a greater cause, such as purchasing a home; paying some interest on borrowed money is fine, as long as the money you borrowed is put to good use. Similarly, managing some technical debt is useful and appropriate as long as the project that generates that debt adds value to your product and your company. Technical debt, like financial debt, becomes a problem when left unresolved: it increases in cost and gets harder to deal with over time.

Continuing with the financial metaphor, technical debt becomes a problem when it builds up to the point where the cost of managing and servicing the debt becomes too great and impedes your ability to invest in future projects. When too many quick and dirty projects rule your project plan, and projects designed to reduce debt are not staffed in your company, your technical debt starts to become unmanageable. If this goes on for too long, technical debt overwhelms the project, as shown in Figure 1-8.

Figure 1-8. Technical debt overwhelming the project

Messy desk syndrome

Imagine you have a perfectly clean desk. Now, take a sheet of paper and set it in the corner. Is your desk messy? No, not yet. Now take 50 other related sheets of paper and sit them on top of the one sheet in the corner. Is your desk messy? No, not yet. Now imagine you have more papers, but these don’t go with the stack in the corner; they are for different projects. So you put them in different locations on the desk that seem to make sense, just single sheets in single locations. Then, over time, you put more papers and documents and books and folders and pictures, one at a time, on the desk. If you don’t know where something goes, you just put it in a new location. You’ll figure it out later. Now your desk is messy. In fact, it’s extremely messy.

This happened because you didn’t have a plan from the beginning, and decided to just “wing it” along the way. You made your desk messy simply by using and working on it. The moral of the story? Unless you have a solid plan for organizing the papers on your desk established at the beginning, and you stick with it, sooner or later your desk will become messy, one sheet at a time.

The same thing happens with organizational pain: it grows quickly when you don’t have an architectural plan from the beginning and you take things as they come. You “wing it,” metaphorically speaking. The result is that you add to your technical debt, and hence your organizational pain, simply by working on and building the application.

Every action you take contributes to that organizational pain, little by little. Your technical debt grows a bit at a time until it becomes overwhelming.

Let’s change our login process to allow saving login credentials in the user’s browser.

Let’s add this new feature to that menu.

Users would prefer that this feature works in three steps rather than the current four steps. Let’s combine two of the steps.

We need to remove the per-session limit on this resource.

We don’t have time to build this full feature now, but we can build this smaller feature, which will make many customers happier. We can do the rest later.

Let’s release this feature this way first, and then we can collect input from customers and modify it to make it more user friendly as we get more input.

Any one of these statements could correspond to a simple set of changes that makes perfect sense at the time. It might not have any obvious impact on overall technical debt at all.

But the little changes…and the little debt…and the little impact…they add up, like the little pieces of paper and other items on your desk. As with the desk that starts clean and ends up messy, each action you take may, individually, seem perfectly benign. Those actions may look perfectly acceptable. But over time, as a whole, they become overwhelming.

Competitive offerings

Maintaining competitiveness is critical to a modern application. This is because the pace of change is accelerating. Technology is advancing rapidly, and new competitors are constantly emerging. Your competitors are moving faster than ever before, and if you can’t keep pace with them you will quickly fall behind and soon become irrelevant. Keeping pace means moving faster and faster, which means being able to adapt and change as the situation demands.

Customers are constantly pushing for more features, lower prices, and better quality. You need to be able to respond to these demands to remain competitive.

New ideas are the lifeblood of a competitive company. When a new idea comes up, you need to be able to quickly adjust and adapt to enable the new idea. This requires agility.

Customers are looking for innovation when it comes to making a buying decision. Companies that appear innovative are more likely to get the customer’s business. This means you need to respond to customer requests and customer needs quickly. Failing to do this will not only cause you to lose customers, but will also cause you to lose your credibility in the industry.

Agility is essential to maintaining a thriving business.

Security vulnerabilities

Your competitors aren’t the only ones innovating. Bad actors are innovative as well.

Never before has the IT infrastructure of our valuable applications been at such great risk to security vulnerabilities and the actions of bad actors as it is today. Bad actors are not only growing in numbers; they are growing in sophistication as well. Bad actors are just as creative at coming up with new ways to attack your application as your competitors are at coming up with new ways to attack your business success.

Bad actors are constantly innovating, improving their attack vectors, and exposing the vulnerabilities of our applications.

As a company and the owner of your application, you must constantly innovate as well, to keep your applications safe and secure. You have to constantly strive to keep one step ahead of the bad actors, and this too requires agility.