A taxonomy of software types

Generally, software falls into three classes; Apps, Tools, and Infrastructure.

The Breakdown

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.

The Team

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.

The Audience

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.

The Benefits

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.

Conclusion

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.

 

Posted in Uncategorized

Feats Instead of Processes

In my last post on Software Capabilities and Feats I said that feats are better [to model in a software capability] than processes, because processes are merely organized, consistent, managed ways to accomplish the feat.

A process is one way to accomplish a feat. The feat is the result you want.

Process is constrained by capabilities. So when I am modeling new capabilities, I should not be constrained by existing capabilities. When I introduce the new capability into the wild, the process will need to “re-form” around the new capability.

A process has steps. If we build software capabilities to support a process, we treat the steps of the process like “feats”. I can model a capability to make that step faster or more effective. That assumes that the step is necessary. In order to decide whether a process step is “necessary” I need to understand how it contributes to the valuable result. I need to understand why I do the step. Read more ›

Posted in Requirements Tagged with: , ,

Software Capabilities and Feats

In some recent conversations, I find that it is hard to explain the notion of a capability. People want to talk in terms of software features or project requirements.

Software capabilities define value in the following ways:

  • enabling the user to accomplish a “feat” in less time than they otherwise would.
  • enabling the user to accomplish a “feat” at a greater scale than they otherwise would.
  • enabling the user (or a group of users) to accomplish a “feat” more effectively than that they otherwise would.
  • enabling the user to accomplish a “feat” that he could otherwise not accomplish at all.
  • enabling the user to accomplish a “feat” better than he otherwise could.
  • enabling the user to focus on “feats” that require decisions, rather than repetitive steps.

Every other benefit of software can be composed from these.

To define value, a software capability must contemplate (model) the “feat” that the user wants to accomplish. Read more ›

Posted in Requirements Tagged with: , ,

The Other Side of Product Investment

If you are a project manager that does software projects, you deal with the “top side” of product investment all the time. Whether your teams are running agile like scrum or kanban, or whether they are running a phase-gated cycle (waterfall), you are focused on the decisions about organizing the investment into packages for release or deployment. You are running the factory which takes requirements in one end and (hopefully) spits working features out the other. You are working with the analysts or product people to ensure that there are enough requirements, stories, or ideas “ready to start” to keep the team occupied.

But what about the other side of product investment? We often talk about return on investment or ROI, but most organizations only use an ROI project to justify the investment. Some will go as far as to attempt to measure “hard” ROI numbers, but frankly even that is missing half the boat because it is hard to measure the impact of software capability on your organizations top line or bottom line. Without a body count, the best we can do is to infer the correlation of software capabilities to a movement in profitability and assume that the relationship is causal. When it comes to softer benefits like risk reduction, customer satisfaction, or employee retention, there is no reasonable way to measure “hard” ROI dollars. Read more ›

Posted in Software Team Tagged with: , , , ,

The Perfect Product Road Map

At the core of every software product road map are two concepts. These are essential to all software product development. We may think of different things, and we may use different terms or even look at them from different angles but at the end, I am convinced that it boils down to only two things:

Capabilities and Adoption.

in my experience, every other thing we do when we build software is a component, or is connected to one of these concepts. I think often that what gets us screwed up, is that that we focus on the “every other thing” from some methodology, or some playbook, or some consultant, and lose the plot on the essentials. Read more ›

Posted in IT Strategy, Software Team

System Replacement Assumptions

I am in the middle of my umpteenth system replacement project.  There are some universal assumptions that are endemic to the user community in every system replacement project.  They are born of hope and frustration.  They are almost universal.

1) The new system will do everything the old one does, only better.
2) The new system will support all of my existing processes and procedures without significant change.
3) The new system will be faster that the old system.
4) The new system will have better data quality than the old system.
5) The new system will address ALL of the shortcomings of the old system.

If you have ever done one of these projects, you know.  They are assumptions that you must actively work against.  They require a constant stream of communication to dispel. I offer you my rationale for why they are never, ever, true. Read more ›

Posted in IT Strategy, Leadership Tagged with: , , , , ,

Decision Let-down

Leadership must recognize that momentum is lost when decisions are anti-climactic.  As a leader, it is tempting to focus on the decisions as your primary responsibility – but that is only half of the problem.  When decisions are not incisive, are not positive, result in no obvious actions or next steps – our responsibility is to keep the team from getting demotivated, confused, or de-focused.   Read more ›

Posted in IT Strategy, Leadership Tagged with: , , ,

The Way Forward

Consider this post by Seth Godin… He spends a lot of time describing the negative, which is incredibly helpful when diagnosing our current situation. But he concludes with the game changer – what happens when you do the opposite of all the bad things…

Sometimes it is so easy to see “What’s wrong” with the current picture.  Everyone is a critic.  It is so much harder to say what we should do instead.

George does the opposite

George Costanza (of Seinfeld) famously decided to live by figuring out what he would normally do in any situation and do the exact opposite.

Sometimes our response, when we perceive that the status quo isn’t getting the results we want, is to be somewhat brutal in our critique of the status quo – and then for all the things we find wrong, propose the opposite…

I’m not saying that the opposite is the right thing, but sometimes just thinking through what the opposite might be is a good way to brainstorm through what options you have.  Better yet, look at what others are doing (that is different from your status quo) and think about the opposite of that.

Thinking in terms of opposites is an easy way to get ideas on the table.

Posted in Leadership

Smaller Bets (Story Elaboration Pushback)

It is always better to spend the least amount of (time, effort, money) to get what you want, right?  If I can get a tasty meal for $10 why

McD's Dollar Menu Combo - Buffalo Ranch McChicken + McDouble with Coke = $3.64

McD’s Dollar Menu Combo – Buffalo Ranch McChicken + McDouble with Coke = $3.64

would I pay $30 or $200 – for the experience of eating – that isn’t about taste.  That is a different thing, isn’t it.  We have different priorities for eating – being full, healthy, tasty, being served, fast service, being able to relax, a pleasant experience, being able to brag about my meal/experience.  Each of these is a different reason for selecting a dining experience. Each of them is valuable to some people some times, but not all people all the time.  The way we choose to spend our money to eat is not that different than the way we choose to spend our money on software capabilities; there are different reasons why we prefer one capability or a means of delivering a capability over others.

These are the principles that I use to guide my story elaboration – and thus my ability to challenge those who would ask me to do more than the minimum… Read more ›

Posted in Requirements, Software Team Tagged with: , , ,

Packing The Box

Do you remember the last time you moved?  Do you remember packing some boxes so full, that they were too heavy to lift after you were done?  It happens.  Especially books and vinyl records.  When you are packing “regularly shaped” high density items, the volume of the box may be too large to contain the weight of the items.  Or it may be that the lifters (I mean you) may not have enough momentary work capacity (strength) to carry the box. Read more ›

Posted in Culture, IT Strategy, Requirements Tagged with: , ,
Google+