Summary:
Software Awareness is a coinage that I
have developed thru the years as an Application Architect and Information
Technology Director. Having developed ERP systems across several vertical
markets and supported many software companies ERP systems I have always felt
that software companies should do more to ensure a predictable outcome for
their customers especially related to Application performance.
The starting point for Software
Awareness lies into a three part observation of software development and its
application. The first part focuses on Software Performance Awareness (SPA).
Problem:
In recent years most IT
and Business organizations have focused on understanding Application Performance
Monitoring (APM), Application Transaction Monitoring (ATM) and Business
Activity Monitoring (BAM) to name a few. Software companies have built new
methodologies in an attempt to understand and document “Application Behavioral
Performance” (ABP) as well as defining new means to capture the “Application
Transactional Path” (ATP) related to the software stack e.g.
Client, Network, Application Servers and Database components. Keep in mind that
these monitoring systems live outside of the Application and have their own
infrastructure requirements. Subsequently and as observed, tracking the ATP may
also lead to an impact on performance even if minimal.
Inherently the value
proposition related to the aforementioned in many cases requires as much
infrastructure as the software that is monitored, needless to say that the
additional exponential cost in Infrastructure, systems and resources precludes
many organizations from purchasing these products, even though Software as a Service
(SaaS) model(s) may provide in some cases an attainable point of entry. Although
the industry has matured, software companies who provide extensive options
around Application monitoring and provide an in-depth outline of the effects still face challenges
when asked to characterize the root cause.
In addition Software
companies have found themselves at odd in properly characterizing “Application
Performance Issues (APU) vs. Application Processing Timeline (APT)” and meet
customer expectations. As an example a business user may portray a 30 seconds
transaction as unacceptable when in effect that transaction performs well within
the boundaries of the application as set by the vendor.
Furthermore, entities who
cannot afford Application monitoring tools must engage in the traditional
support model that requires an endless and costly stream of resources for both
business and vendor to track and resolve perceived performance issues.
For most software
companies, the failure to address software performance relates to drop in software
sales, maintenance revenue and loss of confidence in the offering.
Solution:
Software companies must develop new
methodologies to successfully articulate “Software Awareness” within their
products. The primary objective would
include the characterization of SPA for which would include developing Key
Performance Indicators (KPI) to help visualize the Application state. As such these
KPI would capture and report against the Infrastructure, Systems, Network and
Storage.
Understanding the “Application
Transactional Path” (ATP) will inherently lead to a better account of Application
Processing Performance (APP).
In addition, the development of Active Error Handling
(AEH) specifically designed around the Application ensures that both business
users and supporting entities actively participate in the performance, issue or
bug resolution. As an example, most errors handling windows or pop-up do not
make sense to business users as the content addresses engineers or developers,
therefore why present them. Furthermore these errors do not provide the user
with the actionable option of seamlessly reporting the error, for which by the
time the supporting entity acknowledges the error, it no longer has the
contextual understanding of what triggered the error and therefore inhibits the
duplication of the issue. One option would require capturing these errors through
a global error handler and reformatting them based on their source e.g. Client,
Web Server, Database, etc…, presenting the user with a modal window showing a
generic error message with the option to send an email to the supporting entity
with detailed information around the error e.g. functions, procedures, users and
environment variables, would provide a reproducible context thus accelerating issue
resolution.
Steps:
The following provide a high level outline related to
“Software Performance Awareness”. Keep in mind that providing the business unit
with a keen understanding of Application Behavioral Performance (ABP) will also
lead to better forecasting and capacity planning thus ensuring unparalleled
business continuity for the Business users. In addition, software companies can
now use the data across all their customers to build Business Intelligence (BI)
to predict Application failures.
As
an example, the data collected may show that the use of IE 8.0 with JDK 1.5
precludes business users from running function X. Imagine adding the aforesaid
to the Application Active Error Handling; we now have the option to notify the business
users before the issue occurs. Software companies can also decide to provide
optimum Client-Side configuration to supporting IT organization as an added feature,
thus ensuring a predictable outcome and behavior across the software stack.
1.
Track performance KPI within the
Application
a.
Client-Side
i.
Browser (Type (Mobile, Desktop),
Manufacturer, Version, Service Pack, etc…)
ii.
Add-ons, Java, Flash, Active X
iii.
Hardware type, Tablet, Mobile,
Desktop, Laptop
iv.
Hardware configuration (CPU, MEM,
Storage type – SSD vs. Traditional)
b.
Server-Side
i.
Application Stack, e.g.; JBoss,
Apache, Tomcat, IIS, et…
c.
Database
i.
Database version, service pack,
settings
ii.
Hardware configuration
d.
Network
i.
Internal bandwidth
ii.
External bandwidth
iii.
Customer bandwidth
iv.
Filters
v.
Proxies
2.
Data Growth Forecasting
a.
Queries
i.
Understanding exponential growth
of data ensures that queries are optimized for real-life scenario data set vs.
demo data.
b.
Storage
i.
Drive speed (10k vs. 15K vs. SSD)
c.
Data Warehouse
i.
Data archiving ensures that the
Application always meet performance expectations
Conclusion:
Software
companies should consider adding “Software Awareness” methodology behind their
offering not only as a mean to ensure a predictable outcome to their customers
but also as a mean to lessen the burden of Application performance support in
terms of time and cost. In addition time and cost savings provided to supporting
entities and business users may help develop new features or functions around
the Software stack thus providing additional sales opportunities.
Acronyms translation:
·
Software Performance Awareness (SPA)
·
Application Performance Monitoring
(APM)
·
Application Transaction Monitoring
(ATM)
·
Business Activity Monitoring (BAM)
·
Application Transactional Path
(ATP)
·
Application Behavioral Performance
(ABP)
·
Application Performance Issues (APU)
·
Application Processing Timeline (APT)
·
Application Processing Performance (APP).
·
Active Error Handling (AEH)
·
Software as a Service (SaaS)
·
Key Performance Indicators (KPI)
"The postings on this site are my own and don't necessarily represent IBM's positions, strategies or opinions."
"The postings on this site are my own and don't necessarily represent IBM's positions, strategies or opinions."
No comments:
Post a Comment