The screenshots of your custom-built enterprise dashboard applications are piling up, and I do promise to get back to featuring them. My heart is on the custom-build side, I must admit, but it behooves us to see what the package vendors are offerring in terms of enterprise dashboard software. They do have the edge when it comes to quick deployment (especially against the average corporate IT department thinking about BI dashboards for the first time).
Numerous tradeoffs exist in making this decision. Keeping in mind that we are characterizing this decision as “build all of it yourself” vs. “buy some from a third party, and build the rest”, we will examine each of the following tradeoffs :
1) The Cost of Development Resources
2) Total Time for Implementation
3) Quality of the Resulting Solution
4) Performance of the Resulting Solution
5) Protection of Investment for the Future
1) The Cost of Development Resources
It would be overly simplistic to say that the cost of the third party product is to be weighed against the cost of the personnel that would be deployed to develop the equivalent solution. Sometimes the costs may appear to be similar, but there are a number of other important considerations:
Build:
IT employees assigned to develop an enterprise infrastructure monitoring system from scratch are starting at “square one.” Developing even the simplest of graphical interfaces for the front end often requires research and development of new skills. These employees may be very good at what they currently do, but they are probably not familiar with all the issues associated with building a sophisticated monitoring system. They may be able to do it eventually, but there is inefficiency inherent in this approach. The total cost in this situation is not only in the employees’ time, but also the training in lower-level development skills that would not be necessary if they were building atop a
product.
Sometimes, especially during slow economic times, a company will attribute a lower cost to deployment of their own employees on an internal development project. Rationalizing that they are “already paying them”, the company assumes that the cost is zero. However, even in slow times, it is rare to find a situation where these employees are truly “doing nothing.” If their efforts are applied to the development of a new monitoring system there is certainly a cost associated with it.
The total cost of building the solution involves not only the employees’ time, but also the intangible cost of the inefficiency of using developers without the necessary skills on such a project.
Buy:
Of course, there is a cost associated with purchasing a third party product and learning to use it. There is also a cost associated with the accompanying higher-level development, although it is likely to be far less than that of developing the entire system.
Employees assigned to working with a product will be starting at a much higher level since many of the components necessary for the solution are already in place. With proper training, in a short amount of time they are typically able to produce powerful and effective solutions for the monitoring problems. In addition, the expertise of these employees will be used more effectively as it is applied at a higher level directly to the problems that the monitoring system must solve. They have the
knowledge to effectively make use of a product.
2) Total Time for Implementation
It is obvious that the implementation of a monitoring system built on top of a solid foundation
will take much less time than one built from scratch. However, there are other, even more important, aspects to consider about the development schedule:
Build:
Since an internal do-it-yourself development project begins at square one, it can often
take several months before even the simplest features become available. At that point,
the real work begins, as more complex features can take many months to develop.
Even after a year, the system may have no more capability than what would have been
obtained out of the box using a product.
Developers, even good ones, are notorious for underestimating the time that it will take
to implement a new project, particularly in an area with which they are not so familiar.
This is due not to a shortcoming in their programming skills, but rather a failure to
anticipate the degree to which unexpected problems and surprises will delay their
efforts. It can often take days or weeks to finally uncover why that one object causes
the Netscape browser to crash, for example. Such unexpected problems can result in
huge delays in the project.
Often, the people called on to work on internal development projects are some of the
best developers in the group. While this may seem like a good thing, the fact that they
are so good means that others in the group will constantly be calling on them for help in
resolving some emergency situation that arises. While these developers may be officially
tasked on the new project, the fact is they will undoubtedly be interrupted many times,
sometimes for lengthy periods, as duty calls. This is another situation that can wreak
havoc on the schedule for development of the monitoring system.
All the while this development is going on and delays are mounting, there continue to be
application process failures and bottlenecks causing untold cost to the organization, as
the old way of doing things is perpetuated and reinforced.
Buy:
Typically, within one month of installation, there can be seen an immediate and
measurable benefit to the company in using a package product. Since the product is fully tested and has been deployed in many different environments, it is likely that smooth installation will be followed by a period of rapid progress in development of useful monitoring displays and applications.
By starting with a highly advanced base of features, including a graphics display builder, built-in data access methods, and a powerful and flexible historian, developers take far less time to produce effective systems. Even with the inevitable day to day interruptions, they are able to construct and deploy applications quickly and easily.
Surprises are minimized, as most common issues have already been addressed by the vendor, given its long experience in building such systems.
As the IT department becomes more adept at using the product, the solutions produced
become even more effective and useful. Developers are spending their time advancing
the solution they built in the early stages, far outpacing the benefits that might come from
developing it oneself.
Instead of taking a year to re-invent functionality that already exists in the products, the IT group is quickly producing advanced solutions based on a proven solid foundation. This is a result that is vastly more valuable to the organization. Significant benefits in reduction of downtime and improvement in overall system performance are seen in a very short time.
3) Quality of the Resulting Solution
The quality of the solution produced solely by internal development can be reasonably good.
However, there are some important issues to consider:
Build:
The fact is that internal developers will probably be “reinventing the wheel” by developing a basic application monitoring capability from scratch. As part of the project, it will be necessary to develop a basic foundation for managing multiple dynamic graphics displays, handling the interface to data variables to drive these displays, and important ancillary functions, like historical data archival and retrieval.
While none of these things are terribly complicated on the surface, it is common knowledge that the first implementation of anything is nowhere near as good as the second and third time you do the same thing. Thus, the implementation made by internal developers is not likely to be as good as one developed by a third party with a great deal of experience in the area and multiple revisions of its product.
Additionally, some of the best features in a product come about through repeated exposure to many different customer use cases. This exposure can only occur over a long period of time. It is unlikely that within a single company environment, there will be enough exposure and development
response to result in a feature set nearly as rich as that provided by a vendor.
Buy:
A solution produced using packaged software as a foundation is likely to be much higher quality by many measures.
Typical vendors have experience building high performance graphical systems for monitoring and control of sophisticated applications. During this time, techniques have been developed and honed over many revisions of the product to manage large numbers of graphics objects and data references, to filter data in various ways, and to perform functions on raw data. Exposure to many different types of problems has resulted in a very rich feature set, designed to graphically visualize data in many different ways.
4) Performance of the Resulting Solution
While the internal IT group may be capable of developing a reasonably good process monitoring application, there are a number of areas related to performance of the resulting application that need to be considered:
Build:
Typically, an internal build-it-yourself development project starts out simple. In the zeal to demonstrate something working, a quick implementation is often made, using the most obvious data structures. String compares are often done to find named objects, large tables of data are retained in memory to simplify coding, object replication is ignored, and memory leakage and growth is not considered a problem in the early stages.
It is only after the system starts to be used on a larger scale that significant performance issues emerge. At this point, so much code may have been written using the simpler data structures that it becomes impossible to change without significant effort. Ugly patches and workarounds get applied, which ultimately do not work very well and result in a maintenance nightmare.
The result seen in most cases is a system that performs slowly, gobbles up memory, and often crashes. In time, it becomes very difficult to add new features. Overall, the monitoring system itself becomes a burden and may never actually be used.
Many man months can be spent correcting the results of designs that were well intended, often by very good programmers. Usually, these people have a great deal of expertise in specific business domains, but are asked to develop applications where they do not have the experience. Costs grow rapidly in correcting problems introduced by this approach.
Buy:
In contrast, a solution built on top of a robust package is likely to perform significantly better.
The algorithms and data structures used in the applications have been improved over many versions of the product. They have been specifically designed to manage large numbers of objects and data variables and are optimized to provide best possible performance. Memory usage has been extensively analyzed to avoid leakage and minimize consumption.
What all this means for the IT department is that little or no time needs to be spent reworking code in order to achieve good performance. It can be assumed that the best possible performance is already available by building on top of the existing system.
5) Protection of Investment for the Future
Every few years, there occurs some significant change in the computing environment. This is one of the issues most overlooked when considering how to develop an internal application process monitoring system.
Build:
The internal development group is often consumed by the demands placed on it for designing and implementing the monitoring system in the first place. It is typically not an area of expertise, so there is a need to do research and develop new skills. Usually, it takes all available resources to come up with a reasonably good solution matching the current requirements.
In this process, it is highly unlikely that much thought will be given to planning for ways to build the system so that it can be ported to the next generation computing environment which may emerge a few years from now. That next generation always seems so far off … yet in reality it is often much closer than one thinks. If this issue is not addressed up front, it is likely that in a few years all the work that was done to internally develop a useful monitoring system will have to be thrown away and a new project started from scratch. We see this all the time.
Buy:
While this issue may not seem terribly important right now, many years of experience reveals this to be one of the most costly overlooked issues of all, when you think for the longer term. Protecting your investment against obsolescence must be a priority.
Subscribe to Feed
I guess the story-line could go something like this…
Just thought you might enjoy it! …
