This is the final post in a series that has been focused on providing different ways to think about the job of a modern day software technology architect. The series began with the idea of defining an architecture that blends physical and digital worlds, taking more of an omni-channel approach. The next post expanded on this idea by discussing the era of the Platform Economy and the platform ecosystem. It is here that the idea of three architectural patterns (orchestration, interaction and acquisition) was introduced. Some resources were provided that highlight some starting points into understanding more about platform architecture thinking. One of the more interesting elements presented was a comment by Marshall Van Alstyne (research professor MIT) during a MIT panel discussion, “products have features and platforms have communities.” A second provocative comment in this panel discussion worth exploring is the perspective that, platforms beat products every time. For me this led to a question, “is that true and if not, how do I choose and do I have to choose?” In general, I do believe platforms beat products, and that platforms will begin to have a larger footprint in most company’s architecture landscape…in the right context, for the right purpose to achieve flexible, yet targeted outcomes.
This concept hinges on the distinction between what constitutes a product versus what constitutes a platform.
To put a boundary around our scope, we will limit this post to application software products and application software platforms.
An application software product is a packaged piece of software, compromised of one or more components. This covers a variety of deployment options that could be available, including on premise, in the cloud or as-a-service. Its appeal is that an application software product is designed and deployed to perform a specific function, such as predictive analytics, marketing automation, e-commerce, and product lifecycle management. In general application software products are “proprietary” and controlled by individual companies.
Application software platforms on the other hand is considered a collection of software services that can be combined in multiple ways to produce varying functional capabilities. Platforms also have a number of deployment options including on premise, in the cloud or as-a-service. In general, application software platforms are concerned with open architectures that allow technologists to design, deploy and run individual components that are coordinated together versus an entire package of software which only provides APIs to access pre-defined capabilities. Examples of these type of platforms include the Distributed Services Architecture, The Apache Software Foundation and Deeplearning4J.
Armed with these definitions, it is very easy to get over zealous and think that this lays the ground work for an “either/or” debate, similar to a make versus buy discussion. An either/or approach to software is dangerous and incorrect thinking. Most business environments require both, at least for the foreseeable future. Thus, the key is to know why to choose which technology based on the desired outcomes and culture of the organization.
When selecting software, there are numerous decisions that need to be made and I believe there are truly four key selection criteria that provide the greatest guidance:
- Skills – Skill availability and culture of the organization
- Options – Satisfying a specific need or seeking flexible options
- Adoption – Requiring immediate scale or staggered adoption
- Time – Pressure for time to value or time to innovate.
Potentially the most important selection criteria is to understand the mix of skills that exist and can be acquired at a cost the organization is willing to invest. The benefit of traditional application software programs is that there is a broad availability of skills, training programs and experience to mitigate the risk of selecting the right technology. The benefit of application platforms is the ability to adapt more readily to technology changes and avoid locking into a single vendor for extended periods of time that become painful to change. In the end, the real decision is what culture does the organization have and what investment is the organization willing to make for the desired end state?
Determine if you are solving a distinct business problem versus solving a broader enterprise problem. If the vision is to invest in technology to support a specific business function or business need, then an application software product is likely an appropriate approach. However, if the need is to provide flexibility for the future across an entire enterprise that could impact multiple domains and departments, then the capabilities of a software platform is the more appropriate approach.
Many enterprises are focused on scale that has been tested, which is different than being able to scale. If an organization needs verified customer references of how the software is able to handle volume, reliability and security with strong post-sales support then it’s likely an application product is appropriate. If on the other hand, there is the ability to scale through adoption roadmaps, where growing pains and learning can be tolerated to get to a more desired state, then software platforms are the right choice.
While skills may be the most important decision criteria, time will most likely determine the final decision. In the case where the organization has the experience and the skill and has well defined requirements, with the pressure of getting to value in the quickest fashion for a specific purpose, application products are the way to go. In general those packages that have more “out-of-the-box” capability with minimal configuration and tuning, will be the fastest way to get to value. When innovation is more the driver and there is time to allow for trial and error, platforms are by far the superior choice. They provide the ability to tailor and create in ways that are more difficult to do with a prepackaged piece of software.
In the end, the choices that need to be made come down to balancing need, desire and culture. If the requirements are well known, the purpose and target outcome are agreed upon, most organizations will be just fine selecting either software products or software platforms. With the rapid change of technology and the flexibility that more and more organizations are needing, I believe that software platforms are the direction most environments will take over the next five years.
To really begin appreciating the power of software platforms versus products, I recommend spending time gaining hands on experience with multiple platforms such as those mentioned earlier. After that experience, see if you agree or disagree with my position of the power and eventuality on platforms taking a greater percentage of enterprise mindshare and architecture footprint.