In a prior post, I asked the question: should we redefine the word ‘Application’ now that our definitions do not refer to the same things as they used to. Kevin responded to say that the notion of a component is well understood, and that applications composed of components are similar to the structure of the brain.
So, assuming we don’t change the definition of application, let’s see what that definition used to be and see if we can be meaningful in how we use the list of applications in our portfolio management activities.
An application, in an older definition, might be “a deployable unit of software functionality that provides a business capability to a user, usually involving the collection, storage, and presentation of data.” In previous models, the code that was shared was incidental to the definition. In other words, the fact that two applications would share a few small components that dealt with installation, or with error logging, didn’t matter to this definition, because there was little or no real overlap in the complexity.
Now, in the world of SOA, I may have a portal. In my portal, I have six web parts. Each one presents or updates data through the use of back-end services. Each web part is seperately deployed to my portal server, and in fact, they have substantially different lifecycles.
Each web part would qualify according to the old definition of application. However, none of them ‘store’ data. That is done by the web services. Let’s say that two of the web parts call the ‘StoreData’ service: wpCRUD-A and wpCRUD-B. Let’s also say that three of the other four parts (wpQuery-C, wpQuery-D, and wpQuery-E) produce simple queries from that data using the “QueryData” service, while the last part (wpReport-F) produces reports using the “GetReport” service.
So, in my definition of an application, I can include the services themselves, or they can be considered to be seperate applications. If I include them, then I have App1 which contains wpCRUD-A and the StoreData service. App2 can have only the wpCRUD-B web part, but should it include the StoreData service?
Here’s the conundrum: the complexity of App1 is the sum of a small amount of complexity for the webpart and a larger amount of complexity for the service. Let’s say that wpCRUD-A and B both have complexity of 20 units, while the complexity of the StoreData service has 55 units. Therefore, the application complexity for App1 is 75 units. If you include the StoreData service in App2, then it’s complexity is also 75 units. The total is 150 units.
However, the actual total complexity for these two should be 55 for the shared component and 20 each for the web parts, which is 95 total units. The difference between 150 and 95 is substantial. If we use the 150 in our TCO calculations, will get a different number than if we use the 95.
The problem is exacerbated if you do the same thing for the reporting and query components.
This matters if we calculate the complexity by application. If we do not, and we calculate by component, then the problem doesn’t emerge.
However, our systems for managing a portfolio don’t usually capture the distinction. Our executives (across industry) talk of reducing the portfolio. Therefore, they would see it as beneficial to remove wpCRUD-B because the app count would go down, even though the unique complexity of that app is very very small.
Also, let’s say that this entire structure (the portal and the web parts and services) replaced a single web application that was there before. Therefore, when it was rolled out, the number of applications went up, from one, to three or four or six, depending on how you count them. That said, this model is nearly always less complex, and the total complexity probably went down when the silo app was replaced with services.
So, fundamentally, the discussion needs to be around reducing the portfolio complexity overall, and not portfolio count.
The other problem comes from looking at the portfolio from the standpoint of users. Let’s say that webpart wpCRUD-A is the only web part that users from the finance group can see. Let’s say that the reporting web part is the only web part that the users from the sales group can see. To them, the complexity of the app includes all the back-end services needed to deliver the functionality. To them, if you roll up their application support portfolio, you would include these services in the count of complexity for the sake of understanding how difficult it will be to provision support for the apps in each department.
Executives are not fools. They can understand this distinction between count and total complexity. Even then, as the departmental scenario illustrates, there are some hard choices to be made. However, tools and toolmakers are behind. The portfolio tools in place do not often make this distinction. Those that do have simple “dependency” links, and not “composition” links.
As a result, the calculation of overall complexity is difficult to do, since it requires a detailed and careful construction of the data in order to get good results. This is tough if you have a few hundred applications. It is downright nasty if you have thousands (as Microsoft IT has).
So I guess my challenge is to developers of APM tools (including Microsoft, now that we purchased one).
Challenge: Depict the composition of complex apps from app services in the management system to allow the complexity of each app to be understood, both from the end user standpoint and the deployment standpoint, so that all the reports are well understood.