- Application Management
- What is Application Management?
- How does Application Management Work?
- What are application management Services?
- What does an application manager do?
- What is an Application Manager?
- Why is application management important for the business?
- What is Application Lifecycle Management?
- Introduction to Windows Service Applications
- Service Applications vs. Other Visual Studio Applications
- Service Lifetime
- Types of Services
- Services and the ServiceController Component
- Requirements
Application Management
What is Application Management?
Application Management (AM) is the lifecycle process for software applications, covering how an application operates, its maintenance, version control, and upgrades from cradle to grave. Application management services are an enterprise-wide endeavor providing governance designed to ensure applications run at peak performance and as efficiently as possible, from the end-user experience to integration with enterprise back office functions such as database, ERP, and SaaS cloud functions such as CRM.
In this manner, AM acts as a service operation function that manages and supports applications and key stakeholders who provide operational proficiency or technical expertise through the lifecycle.
Some AM processes include Application Lifecycle Management (ALM) and Application Performance Management (APM).
There are several stakeholder groups in AM, who should work as a team to reach critical decisions such as build or buy, whether an application should be modernized or replaced, or where the application should be hosted.
Some key stakeholders in AM are:
- Application Manager/Application Analyst: Owns the AM process and thus manages the overall application lifecycle. Typically, there would be one Application Analyst or a team of Application Analysts for each major application. Also responsible for performing skills gap analysis and acquiring needed skills or staff.
- Business Unit Owners: Business-level staff members who view applications and AM in terms of bottom-line benefits, increased productivity, impact on revenue, and improved competitive stance.
- Developers/DevOps/DevSecOps: This group of IT professionals are charged with the design, development, deployment, integration, security, and maintenance of applications.
- Application users: Users provide feedback on productivity and performance, and key concerns for users include privacy, and security of the applications.
The ultimate goal of AM is to implement efficient, reliable, and cost-effective code that enables an enterprise to meet its business objectives by ensuring that the required capabilities – both management and technical – are in place, and to further ensure that any technical issues are rapidly diagnosed and resolved.
How does Application Management Work?
Traditionally, AM was part of the IT Infrastructure Library (ITIL) processes, specifically as part of the ITIL Process Map as outlined in the process overview of ITIL Application Management.
Once the build-vs-buy decision for a given application is made, AM stakeholders collaborate with technical teams including DevSecOps to ensure the requisite skills to design, test, manage, and improve the application’s services are on hand or acquired and constantly refined to meet changing environment and needs. Note that the exact functions of an application management system are constantly evolving, just as application development methodologies have evolved from waterfall to agile to cloud-native.
What are application management Services?
Since not every organization has the capability of staffing full time AM positions, or is already dealing with IT backlog, many organizations rely on application management services (AMS) to augment their AM capabilities. AMS organizations enable the outsourcing of application maintenance and monitoring, and AMS firms then shoulder the responsibility of patch management, bug fixes, and enhancements, freeing up valuable IT, line of business (LOB), and DevSecOps resources. Even large enterprises utilize AMS services to help reduce backlogs, as evidenced by a Gartner report showing that IT backlogs were hindering application adoption.
Enterprises can prevent these backlogs – and the user-dissatisfaction, interruptions and other inefficiencies those backlogs cause – by outsourcing the monitoring, management, bug-fixing and optimization tasks for those apps to an AMS provider.
AMS organizations help mitigate continuity risks that occur when key personnel leave, reduce the time required to backfill necessary AM skills, and can contribute to every application from web application to database to custom in-house business code developed on legacy platforms.
For many small/medium businesses (SMBs), AMS providers may be the only reasonable way to achieve a robust application lifecycle management process, given the typically limited IT resources present. The AMS market is rapidly growing, with estimates from Grand View Research indicating that the global AMS market would exceed USD $87B by 2025.
What does an application manager do?
What is an Application Manager?
Application Managers are IT professionals who own the AM process that manages the application software lifecycle within the enterprise. Typically, application managers are not developers or users, rather they are analysts who help define the need for new applications, communicate their findings to other key stakeholders, lead implementation, maintenance, and retirement of applications as part of the IT team.
Key functions of an application manager include:
- Identifying business opportunities for new applications by analyzing workflows and determining where efficiencies can be gained
- Determine whether new application capabilities should be purchased, subscribed to via SaaS, or developed in-house
- If software is purchased, application manager oversees acquisition of infrastructure, installation, configuration, and application lifecycle
- If developed in-house, application manager collaborates with development, DevSecOps, and business units to ensure application meets the defined needs and user interface requirements
- In either case, application managers lead the roll-out to prevent any possible problems from becoming show-stoppers
- Leads problem resolution by troubleshooting technical issues as they occur and develops a solution to solve root cause issues.
- Determines when training is needed and oversees training for both IT and user teams
- Ensuring application’s usefulness, or whether application should be sunsetted in favor of newer application or due to elimination of business function
Application managers are problem solvers, and as such must have solid analytical skills and the ability to develop creative solutions to problems. Since AM stakeholders exist throughout the organization, application managers by necessity have solid communication skills and leadership abilities to present and promote their suggestions and see them bear fruit.
Skills that are most often associated with application managers include:
- Strong understanding of project management
- System analysis including design, development, deployment, and support
- IT troubleshooting
- Business process automation (BPA)
- Database management
- Communicating technical concepts to non-IT audiences
Additionally, experience in developing training programs is a big plus, as are advanced data analytics skills such as Big Data and Machine Learning. Those interested in pursuing a career in application management should also research industry associations such as the Application Developers Alliance.
Why is application management important for the business?
Application management is a key factor in a business’ ability to innovate. By ensuring that business functions are being properly addressed with modern applications, business process solutions can be brought to market more efficiently, quickly, and at a lower total cost. When applications are efficiently managed, more IT resources are available to focus on new business challenges and competitive issues.
Additionally, effectively managed applications are more reliable and less prone to failure that could lead to loss of functionality. Thus, application management can reduce the risk of downtime and improve overall business continuity.
By incorporating new capabilities and monitoring user issues, application management can provide an enhanced end-user experience, which not only increases productivity but also helps accelerate the adoption of new applications or features.
The importance of application management to the bottom line is manifold. Efficient management strategies reduce person-hours spent in meetings, yielding higher productivity. Solid application management practices can reduce the need to retain expensive outside consultants, and lower overall operating costs as the number and frequency of application problems decrease.
What is Application Lifecycle Management?
Application lifecycle management (ALM) describes the ecosystem that manages an application from cradle to grave. ALM is composed of stakeholders, ALM tools, and a management process that spans each phase of an application’s existence.
As enterprises evolve from traditional waterfall to agile and DevOps to cloud-native applications, ALM tools and processes evolve in sync, so that there may be multiple ALM processes in a given organization depending on where they are in their transition from traditional to modern applications.
One goal of ALM is to combine these multiple development practices into a comprehensive management methodology that encompasses legacy, agile, and cloud-native development.
Many enterprises adopting ALM have also embraced continuous integration (CI) and continuous delivery (CD) of applications with frequent releases as opposed to traditional monthly or quarterly releases that embody many changes over a period of time into a single release.
Thus, ALM encompasses the lifecycle of applications by considering the need for maintenance and updates as an ongoing process. ALM provides all stakeholders with visibility into the development process, offering a clear view of where the enterprise is in the development, integration, or maintenance of a given application.
There are distinct phases of the ALM process including
Governance: Beginning with business need, application governance includes the decision-making process on why applications are needed, what problems they solve, what resources will be required to make the application a reality, and what regulatory, security, and other considerations must be taken into account, for example if data must be kept in a certain geography.
Development: Development and DevOps teams begin the creation of the application, increasingly utilizing agile tools and methods to achieve CI/CD, whether for containerized deployments or for traditional VM workloads. The development process includes acquiring or writing code, testing the application, and facilitating its deployment once initial development is completed.
Waterfall development processes separate testing from development, with agile and DevOps teams testing is performed in conjunction with development as a single integrated process.
Maintenance: After deployment, ALM focuses on maintenance for the remainder of the application’s useful life. Frequent releases address both bugs and feature additions, as well as integration with other new or legacy applications. Maintenance also addresses any rehosting necessary if applications are moved from on-premises to cloud and from cloud to containers.
Enterprises often rely on one or more ALM tools to facilitate the ALM process, helping to keep track of version control, collaboration, and requests for bug fixes and new features.
Popular ALM tools include Basecamp and Atlassian Jira, amongst many others.
Introduction to Windows Service Applications
Microsoft Windows services, formerly known as NT services, enable you to create long-running executable applications that run in their own Windows sessions. These services can be automatically started when the computer boots, can be paused and restarted, and do not show any user interface. These features make services ideal for use on a server or whenever you need long-running functionality that does not interfere with other users who are working on the same computer. You can also run services in the security context of a specific user account that is different from the logged-on user or the default computer account. For more information about services and Windows sessions, see the Windows SDK documentation.
You can easily create services by creating an application that is installed as a service. For example, suppose you want to monitor performance counter data and react to threshold values. You could write a Windows Service application that listens to the performance counter data, deploy the application, and begin collecting and analyzing data.
You create your service as a Microsoft Visual Studio project, defining code within it that controls what commands can be sent to the service and what actions should be taken when those commands are received. Commands that can be sent to a service include starting, pausing, resuming, and stopping the service; you can also execute custom commands.
After you create and build the application, you can install it by running the command-line utility InstallUtil.exe and passing the path to the service’s executable file. You can then use the Services Control Manager to start, stop, pause, resume, and configure your service. You can also accomplish many of these same tasks in the Services node in Server Explorer or by using the ServiceController class.
Service Applications vs. Other Visual Studio Applications
Service applications function differently from many other project types in several ways:
The compiled executable file that a service application project creates must be installed on the server before the project can function in a meaningful way. You cannot debug or run a service application by pressing F5 or F11; you cannot immediately run a service or step into its code. Instead, you must install and start your service, and then attach a debugger to the service’s process. For more information, see How to: Debug Windows Service Applications.
Unlike some types of projects, you must create installation components for service applications. The installation components install and register the service on the server and create an entry for your service with the Windows Services Control Manager. For more information, see How to: Add Installers to Your Service Application.
The Main method for your service application must issue the Run command for the services your project contains. The Run method loads the services into the Services Control Manager on the appropriate server. If you use the Windows Services project template, this method is written for you automatically. Note that loading a service is not the same thing as starting the service. See «Service Lifetime» below for more information.
Windows Service applications run in a different window station than the interactive station of the logged-on user. A window station is a secure object that contains a Clipboard, a set of global atoms, and a group of desktop objects. Because the station of the Windows service is not an interactive station, dialog boxes raised from within a Windows service application will not be seen and may cause your program to stop responding. Similarly, error messages should be logged in the Windows event log rather than raised in the user interface.
The Windows service classes supported by the .NET Framework do not support interaction with interactive stations, that is, the logged-on user. The .NET Framework also does not include classes that represent stations and desktops. If your Windows service must interact with other stations, you will need to access the unmanaged Windows API. For more information, see the Windows SDK documentation.
The interaction of the Windows service with the user or other stations must be carefully designed to include scenarios such as there being no logged on user, or the user having an unexpected set of desktop objects. In some cases, it may be more appropriate to write a Windows application that runs under the control of the user.
Windows service applications run in their own security context and are started before the user logs into the Windows computer on which they are installed. You should plan carefully what user account to run the service within; a service running under the system account has more permissions and privileges than a user account.
Service Lifetime
A service goes through several internal states in its lifetime. First, the service is installed onto the system on which it will run. This process executes the installers for the service project and loads the service into the Services Control Manager for that computer. The Services Control Manager is the central utility provided by Windows to administer services.
After the service has been loaded, it must be started. Starting the service allows it to begin functioning. You can start a service from the Services Control Manager, from Server Explorer, or from code by calling the Start method. The Start method passes processing to the application’s OnStart method and processes any code you have defined there.
A running service can exist in this state indefinitely until it is either stopped or paused or until the computer shuts down. A service can exist in one of three basic states: Running, Paused, or Stopped. The service can also report the state of a pending command: ContinuePending, PausePending, StartPending, or StopPending. These statuses indicate that a command has been issued, such as a command to pause a running service, but has not been carried out yet. You can query the Status to determine what state a service is in, or use the WaitForStatus to carry out an action when any of these states occurs.
You can pause, stop, or resume a service from the Services Control Manager, from Server Explorer, or by calling methods in code. Each of these actions can call an associated procedure in the service (OnStop, OnPause, or OnContinue), in which you can define additional processing to be performed when the service changes state.
Types of Services
There are two types of services you can create in Visual Studio using the .NET Framework. Services that are the only service in a process are assigned the type Win32OwnProcess. Services that share a process with another service are assigned the type Win32ShareProcess. You can retrieve the service type by querying the ServiceType property.
You might occasionally see other service types if you query existing services that were not created in Visual Studio. For more information on these, see the ServiceType.
Services and the ServiceController Component
The ServiceController component is used to connect to an installed service and manipulate its state; using a ServiceController component, you can start and stop a service, pause and continue its functioning, and send custom commands to a service. However, you do not need to use a ServiceController component when you create a service application. In fact, in most cases your ServiceController component should exist in a separate application from the Windows service application that defines your service.
For more information, see ServiceController.
Requirements
Services must be created in a Windows Service application project or another .NET Framework–enabled project that creates an .exe file when built and inherits from the ServiceBase class.
Projects containing Windows services must have installation components for the project and its services. This can be easily accomplished from the Properties window. For more information, see How to: Add Installers to Your Service Application.