Internet users and general consumers alike are savvier than ever before. They expect fast response time and good service, and when one company doesn’t provide it, they move onto the next. Application performance management (APM) is a way of getting ahead of IT issues before they affect customers’ expected levels of service.

In the IT world, companies might not know about an IT issue until it’s too late – usually after customers affected by the issue – with the website or purchasing process – contact the customer service team en masse. When this happens, it’s often too late to address the issue without creating a bad customer experience for some. And the company is already on the defensive.

Why Does This Happen?

The problem is that enterprise IT is increasingly complex – a large company can easily rely on hundreds of applications, and these applications must be able to talk to each other seamlessly. Then when an error occurs in one area, it can quickly trigger a domino effect that ends in a bad customer experience.

So, imagine if your company could notice small errors in applications before they cascade into issues for the customer. APM aims to do just this, and there are plenty of APM solutions on the market for companies of all sizes.

Defining APM

Application performance management can also be known as application performance monitoring (and is thus still APM). Without being too technical, both terms can be used interchangeably, as these tools/activities are defined as the monitoring and management of the availability and performance of software applications.

The goal of any APM solution is to maintain an expected level of service. Thus, APM focuses on the detection and diagnosis of performance issues in applications – to find and fix them before they cascade into larger, more significant issues. These can include problems in code performance, dependencies among applications, slowed transaction times, and the overall user experience. A strong APM solution should find the reason for the problem – not just the fix.

Digging Deeper into APM Solutions

As with anything in the IT sector, companies may market an APM solution that isn’t truly APM.

The IT industry research firm Gartner often sets the standard definition for technology practices, and it defines APM as any software and hardware components that monitor performance in five key areas. These are defined below:

  1. End-user experience monitoring (EUM) and real user monitoring (RUM). These tools provide details about response times and errors as they occur on users’ desktop and mobile devices. These details help identify whether issues are related to compatibility, geography, or certain pages and functions. You can learn about the differences between real user monitoring and synthetic monitoring here.
  2. Runtime application architecture discovery modeling and display. This long name stands for something easy to understand – graphics that show how various components within many applications communicate with each other. Ideally these tools should automatically discover the relationships, updating them in real time as they change. This provides a quick, visual way to understand deployed apps and can help identify and troubleshoot problem areas.
  3. User-defined transaction profiling. This tracks every user’s activity within an application. The tools create a single business transaction (BT) each time a user logs-in to an app or webpage, and shows all the back-end processes that are associated with that user session. For instance, a BT can show all the data and communication that occur on the app’s servers and across databases and message queues to validate a user’s credentials and track their actions. To a customer, a single BT, like purchasing a shirt online, can involve hundreds of smaller transactions and touchpoints across various applications. For instance, verifying the user’s log on, seeing availability for what’s in their virtual cart, checking with banks in respect of payment methods, serving up delivery information, etc.
  4. Component deep-diving monitoring in application context. This helps troubleshoot complex code issues by recording and measuring internal app components. For instance, the call stack of code execution and time will be recorded in an application server, and SQL queries, statistics, and procedure executions will be recorded for a database server.
  5. Analytics. When applied to APM, this broad term can include basic report generation of raw data. More sophisticated systems (and some would say “true” APM solutions) will also baseline and correlate data, providing actions that can help identify and solve issues in real-time.

Benefits of APM Solutions

Essentially, deploying an APM tool provides companies with early warnings – it’s like checking the weather so you know to bring an umbrella, instead of arriving soaking wet at your next meeting.

The above five dimensions of APM alert IT about subpar performances in applications before they become significant (business) problems. In continuous delivery environments, APM also helps IT teams know about weaknesses before and during releases, so they can quickly address them.

When APM solutions first debuted in the market, they focused on finding issues in code, databases, and servers and alerting IT as quickly as possible. Start-ups challenged these by going a step further, finding the root cause of the issue(s). Thus best-in-class APM solutions now not only see the issue, they also analyze its impact and provide actionable paths to fixing it, all with real-time reporting.

Ultimately, the primary purpose of APM solutions is to prevent small issues from snowballing into major problems. However, companies that have successfully implemented APM tools report another major benefit – IT and business units can now use a single source of information – the raw data made digestible in APM tools – to understand how an error in IT can have a significant impact on a business unit, allowing for better collaboration.

Choosing the Right APM Solution

While there are specific functions that define a strong APM solution, there are many options on the market. Consider these options when deciding which APM option is best for your company:

  • Complexity. Will your APM solution need to manage a few applications, or hundreds? Are these applications all located in-house, or are they in the cloud as well?
  • End user. Some APM tools are geared specifically for developers, which may be too restricting for non-dev users.
  • Visual representation. How necessary are graphics for your team? If many people will be accessing and relying on this information – like sharing a dashboard with C-suite executives on a big sales day – graphical dashboards can help relay raw data much easier. But these capabilities may be less important if only data experts are interacting with the tool.
  • Scalability. Does the APM solution only need to solve your application/service management problems now, or will it need to scale much larger as your operations grow?
  • Cost. APM solutions run the gamut in terms of cost – simple, stripped-back tools are available for free, while more features, more users, and more scalability will require a higher pricing package.

Is your organization fully benefitting from APM solutions? If so, what other advice would you offer? Please let me know in the comments.

If the goal of your organization is to provide the right IT/business services to your customers, whether internal or external, service portfolio management is a vital step towards meeting governance requirements and delivering value. In terms of available best practice, service portfolio management is an enabling part of ITIL and something that IT organizations should be undertaking.

On the surface, service portfolio management seems simple. It’s the full portfolio of IT/business services available to customers, with its purpose – in my opinion – being to help provide business justification for each service by ensuring they deliver maximum value within managed risks and costs. This end-to-end practice offers many useful benefits, and yet, for many companies, it isn’t employed to its fullest extent.

Defining Service Portfolio Management

In ITIL, service portfolio management is the management of a service portfolio, where this portfolio lists information related to the service and its current status, plus the history of each service. The service portfolio is typically viewed in three parts:

  • The service catalog which provides an overview of all services that are visible, and buyable, to customer.
  • The service pipeline which captures the status of any services that aren’t yet live and visible to customers, typically because they’re proposed services or under development. This portfolio segment also details the future growth and timeline for each service.
  • The retired services catalog which details all services that have been retired and stores any essential historical information.

The purpose of maintaining this information isn’t just to have a service portfolio though. The real value of service portfolio management comes from justifying needs based on inherent business value.

This information enables managers to assess the quality of the services, as well as the associated costs. Ideally, managers can decide which services customers currently use, anticipate what they may need soon, and what they no longer need.

With a well-managed service portfolio helping to answer these questions:

  • Why should a customer purchase this service?
  • Why should a customer purchase this service from our organization?
  • What’s the price and chargeback system?
  • What are our strengths and weaknesses and our priorities and risks?
  • How do we allocate our resources and capabilities?

Service Portfolio Management Vs. Product Portfolio Management

Some companies utilize product portfolio management and assume that it and service portfolio management are the same concepts and provide the same business justifications.

Unfortunately, this isn’t the case. Because as their names suggest, there are differences between products and services, and using them interchangeably does a disservice to the provided customer value as well as the enterprise bottom line.

Traditionally, products are the delivered, purchased good that are tangible. Of course, in IT, something tangible is commonly a digital tool such as software. Services, on the other hand, offer at least some intangible value. Whereas a product might be an application that solves a specific problem, the service can include customer service, transition assistance, and management. And the service facilitates the outcome that the customer wants and expects.

Service Portfolio Management Vs. Project Portfolio Management

Each new service, or change to an existing service, should be justified by clear business needs in order to establish the value. And service portfolio management should track these investments through the lifecycle of the service, from service design through transition and operation, and eventually to retirement and decommissioning. It should also monitor the business strategy for the service, and the ability to execute on this strategy, such that these are dynamic and transparent.

There are definitely commonalities with project portfolio management (PPM)…

While service portfolio management is tracking services, PPM is tracking projects in the same manner – making decisions on investments. But the problem with PPM is that it often stops short, when the project ceases – and as a new service reaches customers on a daily basis – with PPM no longer measuring value at this point.

This can create a rift between App Dev and IT operations, with a difference between what the business expected to the project to deliver and what the customers actually receives (in service terms).

Thus organizations need to recognize that service portfolio management and PPM are related, and that both have their place in a successful ITIL deployment. With industry experts stating that service portfolio management should determine the role of PPM, and not the other way around.

The Benefits of Employing Service Portfolio Management

Employing service portfolio management may involve a radical re-do for all business units involved, but its benefits – and the benefits of a transparent service catalog – are measurable:

  • Customers understand exactly what you, as a service provider, will deliver
  • There’s cradle-to-grave transparency into value, costs, and risks
  • Services in the pipeline can be monitored as well as operational services
  • It helps to justify proposed services and major changes to existing services

Ultimately, tracking the value, cost, and risk of every service your service organization provides also helps to position it as indispensable to your customers, because you know – quickly – how valuable a service is.

So, how is your service portfolio management? What would you add in terms of benefits and tips? Please let me know in the comments.

Code is the DNA that makes your programs and IT services function. It’s the foundation of any development project. And something as small as an out-of-place character can mean the difference between a development project that works as it should and one that doesn’t perform well.  

Needless to say, it’s important for developers to be able to identify potential weaknesses in code. Code smell is an indicator that enables developers to answer a mission critical question: 

Is there a better way? 

What’code smell?  

In short, code smell is a warning sign that can only be observed by someone who has a fine tuned “code nose.” This typically means code smell is observable by developers and is a surface indicator of a deeper problem. 

The types of problems that can be indicated by a code smell are not usually bugs that will cause an entire system crash – and developers are well trained to uncover logic errors that cause bugs and system failure. Code smells are much more subtle than logic errors and indicate problems that are more likely to impact overall performance quality than cause a crash.

Classification of code smells and solutions 

There are five unique classifications of bad code smell that you might encounter as a developer. Here’s what to look for:

  1. Bloaters 

Smells in the bloaters category include long-method, large class, primitive obsession, long parameter list and DataClumps. Let’s take a moment to examine each of these in more detail: 

  • Long method. As a general rule of thumb, methods should be questioned when they are longer than ten lines. If a method contains too many lines of code, it can impact performance. This occurs when developers add to code, but they don’t take anything out. If you need to comment within a method, you should split out the lines of code into a new method. If an explanation is required on just a single line of code, it should still be separated from the original method. Using descriptive headings can help tell other developers what this method does without having to look deeply into it.  
  • Large class. Classes start small and bloat over time. A class is considered large when it contains many methods, fields, and/or lines of code. Here’s a simple fix – if a class has too many functions, split it up using commands like Extract Class, Extract Subclass, and Extract Interface. 
  • Primitive obsession. This code smell typically occurs when a developer has decided to make a primitive field to store data instead of creating a whole new class. It includes issues like using primitives in place of small objects and the strategic use of constants. There are several different ways to address this problem. Firstly, if you have a lot of primitive fields, see if you can group them by class. Use commands like Introduce Parameter Object and Preserve Whole Object if the primitive values are used in the parameters of the method. If the primitives contain arrays, change them with the Replace Array with Object command. This may seem like a lot of effort but the benefit is the code becomes more organized, understandable, and flexible. It sets it up for more building without bloating. 
  • Long parameter list. If you include too many parameters for a method it will lead to a code smell. Three to four parameters maximum is the standard. Anything beyond that can cause a problem. To begin resolving this code smell, replace arguments with Method Calls where possible. Or use Preserve Whole Object to pass an entire object to a method instead of groupings of data. This will simplify the code making it shorter and easier to read.  
  • DataClumps. Different pieces of code that contain the same variable groups should be turned into their own classes. When this fails to occur you get a DataClumps code smell. Like the above solutions, resolving this code smell means simplifying the data used. Introduce Parameter Object and Preserve Whole Object commands are satisfactory ways of doing just that.  
  1. Object-orientation abusers 

The object-orientation abusers class contains its own challenges. These include switch statements, temporary field, refused bequest, and alternative classes with different interfaces. The common ground between all of these is that they all relate to errors in object-orientation programming. 

  • Switch statements. Switch and Case statements are relatively normal in object-oriented code. A single switch can have code placed throughout a program. It’s essential to find all places where that code exists and modify them when making a change. There are several ways to address this code smell. One such way is to use a command like Extract Method and Move Method to isolate a switch code and put it in the correct class. The command you use is going to depend on the conditions of the switch. You may need to Introduce Null Object or Replace Conditional with Polymorphism. The key to fixing it is to understand what you’re trying to accomplish and whether you need to move the method, create a new class, or break into smaller methods to enhance understanding and performance. 
  • Temporary field. Code smell occurs with temporary fields when they’re empty. That’s because temporary fields get filled under specific conditions. Most often a problem occurs when temporary fields are created for use in an algorithm and go unused the majority of the time. These temporary fields can be moved into a separate class all of their own via the Extract Class command, or integrated into the position of conditional code via Introduce Null Object. 
  • Refused bequest. This happens when a subclass doesn’t use all of the methods and properties passed down by its parent class. The unused methods can cause a code smell if not properly addressed. There are two ways to successfully address this, but first you have to decide if the subclass really belongs to its parent. If the answer is no, break it out with the Replace Inheritance with Delegation Command. If yes, remove any superfluous fields and methods from the subclass to clean it up. 
  • Alternative classes with different interfaces. This code smell presents when two classes perform identically to one another. It’s usually caused by a simple mistake that occurs when a developer doesn’t realize another class already exists that performs the same way. You can solve this by renaming problematic methods to make them the same. Or you can make parts of them the same like the parameters and implementation of methods. If the duplication only exists in part of the method, use Extract Superclass to create a subclass of methods. Once the appropriate changes have been made you can delete the duplicate class. 
  1. Change preventers 

The smell known as change preventers hinders further development as the name suggests. Basically, if changes are made in one class or method then changes have to be made in other classes or methods as well. 

  • Divergent change. This smell means you have to make changes to many methods within a class because you made changes to a class. An example of this would be adding a new product to an e-commerce platform and the new product impacts a number of functions on the site. This usually happens when people who don’t know code well enough try to copy and paste or use code from other sites. Without the knowledge of personalization, errors occur. To correct this, you can use the Extract Class command to separate the behavior from the class. If the issue stems from multiple classes having the same behavior, you may want to combine those instead. 
  • Shotgun surgery. This occurs with any modification that sets off a cause-and-effect chain, where you have to make minute changes to a number of classes. This usually happens after behaviors have been split up into many classes. To put them back together again use Move Method and Move Field to create a single class of relevant behaviors. 
  • Parallel inheritance hierarchies. These happen when you find that while creating a subclass for one, you have to do the same for other classes. Making changes becomes harder as new classes are created. Luckily, this problem is solvable in two steps. Point instances of one hierarchy to the other, then de-dupe the referring class using Move Method and Move Field. That said, it may be prudent to ignore this smell at times. Sometimes trying to untangle a mess of parallel inheritance hierarchies creates an even bigger one. 
  1. Dispensables 

Dispensables live up to their name. It’s coding that wouldn’t impact the program if it was removed completely. In most cases, removing dispensables results in cleaner and more understandable code. Each type of dispensable code smell is explained below, but since these are dispensables they have a quick and easy fix  just delete them. 

  • Lazy class. A lazy class code smell indicates that code is underperforming, or essentially not doing enough to afford your attention. 
  • Data class. It’s a class that’s just a data set for other parts of the program and is not logical and thus unnecessary.  
  • Duplicate code. As the name suggests, duplicate code occurs when almost identical code is implemented more than once. 
  • Dead code. This code smell means that a code does not function or serve any purpose. 
  • Speculative generality. This is a symptom of trying to anticipate all the coding needs of a specific program from the start. As you develop the project, unnecessary code can be removed. 
  • Comments. This code smell is triggered when a method is filled with comments. Many are likely unnecessary to the overall functioning of the program. 
  1. Couplers 

This grouping contains smells that encourage coupling between classes.  

  • Feature envy. This smell happens erroneously when features have been moved from one method to another. The result is the method is confused and tries to access another object’s data. Implementing best practices is the best way to avoid feature envy. When changing multiple objects at once, keep everything in the same place. If you absolutely have to move a method use the Move Method command. If you’re only moving part of the method use Extract Method to achieve the result you desire. 
  • Inappropriate intimacy. This smell is an indicator that one class is intermingling with another class via fields and methods that belong to the other. A best practice is to check classes that have spent a lot of time with one another for this issue. If the referred class doesn’t need its parts, resolve this with the Move Methods and Move Fields command. If it’s more complicated than this, you can Extract Class but you’ll also have to use the Hide Delegate command on the class so it works for both parties. For mutually interdependent classes, use the command Change Bidirectional Association to Unidirectional. If the existing relationship is between a superclass and subclass, use a command to replace the inheritance of the subclass. 
  • Message chains. A message chain is a series of calls in code that start with a single client. The client requests an object, and that object requests another. This leads to a chain of objects stemming from the client. If a change is made in any of these objects you need to make changes in the client also. By using the Extract and Move Method commands, move the object at the end of the command to the beginning. Otherwise, you can delete it if it’s excessive. 
  • Middle man. Cut out the middleman by remedying smells whose only purpose is to delegate action from one class to another. This is sometimes an offshoot effect of fixing message chains as described above. The command Remove Middle Man is a fix for this issue. 

Is There a Better Way? 

While code smells don’t usually deal with critical programming errors, they do impact overall user experience (UX). In this technology driven world, UX has become an important topic of conversation working its way from being an added bonus to an essential component of any program or website. Even Google has updated its algorithm in recent years to encourage greater UX. 

Anticipating the needs and desires of end users is an important part of development. And one way to save time in the development process is to acquire a fine-tuned code nose that can help sniff out potential problems. 

If this is new information to you, would encourage to spend some time with code smells to perfect your skills. Maybe, for now, it comes down to just asking “Is there a better way?” as you work through your code. 

Image Credit