Generally, software falls into three classes; Apps, Tools, and Infrastructure.
Apps – or applications as they were formerly known – are software built to help a user do some valuable activity, like check a bank balance or edit digital images. While the end user must learn how to use it, an app is useful without further development. Some apps are configurable, so can work differently for different users or organizations, but they are still focused on solving problems or delivering value related to some specific functional domain.
Tools – are software that are more general purpose, but with a specific flavor – that they are designed so that users of these can use them to “fashion” applications for themselves or other groups of end users. Tools express their own user experience, but are not always immediately valuable without some “fashioning”. Tools can range from Microsoft Excel to Sharepoint to web content management systems like WordPress, to giant ERP systems like SAP or Peoplesoft. Many business intelligence product fall into this category.
Infrastructure – are software that really has no end user experience. They are designed completely as a foundation for other software to be built upon. This would include any software whose primary interaction mode is through API (application programming interfaces) or CLI (command line interface) patterns. Products like databases, middleware, application servers, application frameworks all fall into this category.
So why is it so confusing to people? Because technology has its own functional domains. These classes are not mutually exclusive, in that for one user it is an application and another it is a tool. With add-ons, extensions, or plug-ins it becomes even more confusing, as these constructs blur the lines between tools and applications even further. Plug-ins for a tool, may be applications focused on one functional domain.
With all that said, for a given audience (user community) a given software product can be thought to act as if it belongs to one of these classes.
Why is this important? Because our delivery, integration and support staffing models for these classes should be different.
Applications typically have a relatively narrow (business domain) user community. Support and delivery teams tend to have or develop significant subject matter expertise related to business domain activities. They may rely on vendor expertise for guidance and/or software implementation projects. They may have significant integration expertise and software development expertise within the infrastructure that the application is built on. Application resources need industry understanding and may want to participate in broader user community groups for the application vendor.
Tools typically have a broader problem domain focus that slices across business domains, so their user communities are co-mingled across businesses. Support and delivery teams tend to have less direct business domain expertise, but more problem and solution application – in that they understand how the tool can be applied to solve a range of problems that any business might experience. They are less concerned with software development, or integration except in general patterns that are required to enable their tool. Tool resources need to have an understanding of the competitive landscape in the tool’s domain – they will want to participate in industry conferences around the problem domain where many vendors come to present and to demonstrate.
Infrastructure typically are not concerned with applicability to business domain. Their customers are the tool and application support and delivery teams, rather than the end users themselves. Support and delivery teams are concerned about installing infrastructure and repeatability, maintaining sustainable practices across many instances of a product, keeping some reasonable principles around staying current on software versions, and applying critical patches and fixes from the vendor. Infrastructure resources may be the heavy hitters – with deep expertise in tuning and building against the product, but they may also be constrained by standards, to keep things sustainable.
When new infrastructure software is selected, expertise is often unavailable, and the initial sets of tools or applications that sits on the infrastructure foundation are often the victims of infrastructure learning or of product immaturity.
Free and Open Source Software makes everything more confusing. The relationship between the support and delivery organization and the “maker” of the software is changed. Open source software benefits from a “federated” maker model, meaning that any user of the software can also “contribute” to the making of the software. Organizations that want to extend the software or change it, have access to the source code so that they can alter it. Depending on the license agreement, they can choose to keep those changes private, or they can contribute those changes back to the community so that others can also benefit. They might even decide to “fork” the product, making, in effect, their own version or own brand. This greater control and role comes with a need to express greater responsibility and to maintain greater expertise. Corporations that use open source software should always contribute some resource to maintaining or improving that software.
How does this help?
Software taxonomy alone is not that valuable, except in helping understand and focus the delivery and support staff components. However, there are other elements of the picture that can help bring focus to the software portfolio.
When I think about any piece of software, an OS, a compiler, a database manager, a report generator, an application server, an IDE, a word processor, a spreadsheet, an ERP platform, a business vertical application. It doesn’t matter what kind of software, what drives how I think about it is its beneficiaries. Who (actual people) who benefit from either using the software directly, or via some secondary usage process – as part of an integrated universe, or because they use some software that “relies” on this one. Those people may not even be aware that they benefit from that software, or frankly that that software exists. The reason that it exists (in that instance) is to produce that benefit.
In the context of a business venture (enterprise) I think about how those benefits impact those people in terms of their contribution to cost and revenue. I think about a per user quantification of benefit in terms of cost and revenue impact, versus one who does not use the software (receive the benefits). Then I think about the objections that some users and leaders raise relative to adoption of the software and ask how can we get more people (users) to get those benefits (adoption). Sometimes those objections reveal cases where the benefits are reduced by some flaw in the software the prevents the benefits from being fully realized.
Traditionally, many organizations constructed application portfolios by audience. This works well when there is little in common between business units or client groups. It can lead to duplication of assets across portfolios as well as some complex integration challenges. Platforms like SAP or Peoplesoft can be hard to govern in this audience driven structure, as they were designed from the beginning to become enterprise oriented, and configured for each audience.
Applicability to Business Process
This is where enterprise architecture or business architecture can really help. A business architecture model can be used to map how benefits are realized from each software asset that is deployed. An integrated business capability model (or activity model) would explain where integration between software assets would be valuable.
Application Portfolios that align with business domains could be defined and that would enable more consistent software capability location (deciding within which software product a capability should be housed). This combined with a reasonable taxonomy provides insight into governance and staffing to minimize duplication and unnecessary integration.
Applications products designed for this model, will need to solve a multi-audience challenge, as the business process may have many variants depending on the audience. This may start a drive towards investing in more configurable more extensible systems, both internal build and vendor products. Moreover, platforms that are used in more diverse ways will need to be more conscious of scale, as different audiences will grow utilization and demand differently. Most organizations that have invested in enterprise platforms have found there performance subject to configuration challenges. Without careful implementation, performance can become a constraint, or even an inhibitor to the benefits realized from the product.
So what, then? I think of software as an asset that we invest in to get that benefit. So we ask ourselves is questions relative to those benefits and that investment:
1) Can I get more benefits from the software I have already invested in?
2) Can I get the same benefits by investing less?
3) Are there benefits that I want that I am not currently getting from any software?
4) Are there other products/assets that could get me the same benefits?
5) Are there companion products/assets that could increase the benefit I get from ones I have already invested in?
I also think of questions about benefits and sustainability:
1) What must be done to ensure that the asset I have invested in continues to produce that desired benefits? (maintenance)
2) What do I do when the benefits produced no longer align with the benefits desired? (suitability)
3) For how long can I reasonably expect this asset to produce these benefits? (lifespan)
The Investment Process
The way we invest in applications is largely through projects. How the taxonomy informs our investment strategy is something that each organization needs to work out for themselves. In theory, we should be working to deliver the most business value for the least investment. Business value is delivered out as apps and potentially tools. So from this perspective, investment in infrastructure seems like sunk cost – but not all infrastructure provides app and tool teams equal value – so we must perceive the infrastructure is not to minimize the expense of support or to minimize the cost of build, but to maintain a balance between providing app and tool delivery teams the value that helps them do their job more efficiently against the desire to keep operating expense for that infrastructure as low as possible while meeting end user non-functional requirements like performance, availability, storage capacity or peak scalability.
Any organization that invests heavily in software, needs a rational approach to evaluating their investments. Treating software assets as a portfolio and reasoning over the entire portfolio works up to a certain size and diversity. They some other categorizations are necessary. The recognition that technology itself is a business domain with its own process automation challenges is important. Being able to group the portfolio by some reasonable means is critical, and being able to understand how each software asset type behaves in the portfolio is also important, as that changes the investment process.