The application platforms we are dealing with today encourage outdated software design processes. A better way
for development managers to think is in terms of deploying capabilities to a particular environment that has the ability to interact with other capabilities. This eliminates the artificial walls between applications. It may, in fact, for some advanced enterprise architects, represent a new view on SOA infrastructure.
That is at least one take away from a discussion with Kirk Knoernschild, a research director with Gartner Group. Enterprises are beginning to uncover a fundamental mismatch between the way code is developed and the business value of the development process, argues Knoernschild. “We have taken this notion of an application that runs in its own process that we are accustomed on the desktop and essentially carried that over into the notion of an app on a server,” he explained.
“Why do we even need the notion of an application on the Web?” asked Knoernschild. “It is an artificial notion that constrains how we go about building, deploying and managing software. Instead of application, we need to think in terms of business capabilities, the business process and business activities. “
A significant contributing factor to this disconnect lies in the way in which new code is funded. The challenge is that this process has developed a monolithic application mentality, which makes it easy to add too many competing elements to the finished product. He noted, “Before we know it, we are left with application bloat. We have this all of these applications and some do the same thing, while others are unique.”
The source of the problem is caused by thinking about the development process in terms of applications rather than metrics which are meaningful to the business. Thinking about code in terms of application focuses the attention on metrics like project cost and time to code, which detract the focus from more significant metrics that relate to the end product.
Traditionally IT focuses on IT metrics like cost, time to market, and the number of defects, code quality and test coverage. Perhaps those types of metrics are useful for assessing how streamlined the development process is – but there are other values to consider.
Organizations also have to look at the value their software provides to the business after it is developed. Just because it cost $2 million to deliver a project that is on time and on budget, does not mean the system provides the value the organization needs.
Knoernschild said, “Understanding the business value is also very important, and that is an area where a lot of organizations tend to fall short. That can come in a variety of forms such as worker productivity, customer satisfaction, and retention.”