Every company is a software company, and every software company might to be a service provider

Software is pervasive. Except perhaps for the one-man (or women) burrito-like shops in the streets, every business runs on software. And they are an exception if and only if they do not accept credit card payments or use online grocery delivery services to refill their raw materials stock. Every company is a software company at the end of the day, either a software-consumer only or a software-development-and-consumer combo.

For those enterprises that do in-house software development and then use that software to run their business, even if it is just a portion of the total software being used, the traditional software development lifecycle might not be appropriate in some circumstances, as we will see in a minute.

An for those enterprises who’s business is to develop software for other enterprises or individuals to consume, the traditional software development lifecycle might not be appropriate either.

By traditional software development lifecycle I do mean the process that creates a software product at the end. I do not care if it is waterfall or is agile, the only thing that matters me is that a software product is created as a result of that process. It has the following characteristics:

• Many features. Differentiation of the product is based on having as many features as possible for as wide an audience as possible. Products are rarely targeted to specific roles or customer needs.
• Mean time to failure. As with traditional manufactured products, its main focus is mean-time-to-failure: products are better if they have few failures.
• Slow update peace. Software product updates are relatively uncommon; it may be through patches for fixing bugs, through service packs to add new functionality, or through entire new versions. And development time for software products is usually large, followed by a maintenance warranty, and then a rest period before starting over.
• Unknown consumption habits. Once products are released, is hard to know how they’re consumed by users, and take decisions based on usage patterns.
• On time, on budget. Most important priority is to release products on time and on budget.

In addition, as with traditional manufactured products, reliability is perceived from the perspective of each individual unit. Providing reliability requires controlling quality within the production process. When users experience product problems, they are usually willing to wait until office hours for their problem to be addressed. A problem rarely impacts more than one person at a time. And usually it’s clear for users when problems are due to issues in the software product, as opposed to issues in the environment in which the software runs.

But any of these businesses might be affected by today’s transformation on software demands:

• Your company develops an mobile software application, it can be a line-of-business application in the enterprises world, or it can be another specific-purpose software application in the marketplace for the consumers world. In the second case, most of these applications at least do store some data or do some kind of processing in a remote back-end, which puts them in the same group as those in the first case: mobile applications that consumes remote services.
• Your company does electronic business with other companies, it can be exposing internal processes through software where others can participate, or use software applications to exchange information in order to complete a transaction. One way or another you are either providing software based services, or consuming them; probably both.

Did you notice the word software at the beginning of the two previous sentences and the word service at the end? It is not casual –I wrote it that way- but that is what we are and will be seeing in the foreseeable future: mobile software applications that consumes some kind of remote service and software based services exposed for others to consume.

If you feel that any of the two before mentioned categories do apply to your company, either if you are creating software for your own business consumption or in the business of developing software for others to use, and you are still developing software as products, guest what? You are not developing software, you are providing services. I do call these software-based service providers. And that is a completely different beast, want to know why? Let us see:

• Reliability and agility over features. Differentiation of the service is based on highly reliable capabilities that fit a specific set of market needs. Effective services emphasizes reliability and agility over features.
• Mean time to resolution. As with traditional utility services, its focus is mean-time-to-recovery: failures will happen, so services are better because of its fast recovery.
• Continuous updates, continuous development. Software updates are continuous; they might release new features or entire new versions very frequently, and fix bugs on a daily basis. Software development for services is usually continuous; they might have release cycles, but usually those cycles are very short.
• Detailed usage patterns. Usually it’s possible to collect very accurate and huge amounts of usage data, driving more meaningful decisions.
• Up and running at appropriate costs. Most important priority is to have the service up and running, keeping the appropriate operating cost.

Furthermore, as with traditional utility services, reliability is a function of the entire system. Providing reliability requires real time, proactive monitoring of the behavior of every system component. When users suffer service outages, the impact is much wider, with one problem impacting a wide array of customers. Response cannot wait for office hours. Product support has to be ready 24x7x365. Users don’t care where the issues are when service outages occur. They might be in the software the service is based on, or in the datacenter, or in the network, or in any of the dependent components

You cannot keep pace with change requests and do not have enough agility to accompany businesses transformations? You have conflicting requirements from different business units or different users groups? You cannot find a good way to organize your software development and software operations teams? Guess what, your software factory is probably not organized as a service provider needs to be organized.

Software factories are organized around software products while service providers are organized around services. And you still wonder why it did not work?

Organizing teams around products means two things. One: you have a team by product, some members can be shared among teams, but teams do work for a product. And two: you very probably have segregation of tasks inside teams: business analyst, architects, designers, developers, testers, and operators if you do run your own software. Does one product use others? Of course, except if you have monolithic giant piece of software, in which case you are way worst that the rest of us, and have more urgent and important problems to solve. Each of the roles of a product team I mentioned before, does work for their own product. They really do not care about products using theirs products and certainly they do not control the other products they consume. And the transition from development to operations looks like developers throwing something over a fence to operators to catch… who cares what happens in the other side? There is always a revenge, operators can always fill bug fix request to developers.

Organizing teams around services, means that a service team has everything it needs to deliver the service and fulfill the service level agreement. There is no fence. Service owner, business analysts, developers, testers and operators sits together upfront to define how the service itself, and the service development process, will look like, end-to-end. Radical, isn’t it? Yes, but that is what you need: An operator telling a software developer what kind of automated deployment, monitoring and telemetry capacities he will need in order to operate the service. These are non-functional requirements and architects and software developers are used to deal with them. A tester telling a software development the way he or she should design the software for him or her to being able to effective and efficiently testing it. These are non-functional requirements too. A software architect or developer telling the service owner what can or cannot be built given time and budget restrictions. Sounds crazy, but these examples are just business requirements, the service owner should be used to deal with them during service definition.

If you think that services are just on the outer layer in contact with the outside world, you are plain wrong. The very same concept can be used in inner layers, in what I love to call the service-oriented enterprise architecture. It is not the same as the plain old service oriented architecture, where application services was the cornerstone. I am talking about business services, application services, and infrastructure services, all organized in the same way, relying one on each other via well defined operation level agreements from the service consumer side, and service level agreements as part of clear service definition from the service provider side.

Biggest software companies (well, it depends on your definition of big) are in fact software-based service providers (Microsoft, Google, Amazon, Facebook, Twitter, Whatsup, Apple, and so on). Your company might not be as big as those, but if it is a software-based service provider, you might have more things in common with them that you think. Someway or another all of them do organize behind the services they do provide. Why you do not?