If you've stumbled upon this blog, it may be because you are working for an Independent Software Vendor (ISV).
To give you a bit of background, I've been working for a mid-sized ISV (200-300 employees) for close to 8 years. I work as a software architect in the R&D department of the company, which sells a large JEE-based (Java Enterprise Edition) product to our customers.
During my time working for this company, and with my interactions with the IT departments of our customers, I have noticed that there are numerous constraints that must be considered during various stages of the product lifecyle of which our friends working in IT departments are not burdened.
These constraints affect, but are not limited to, the following:
- Technology stack
- Systems architecture
- Customized business functionality
- Software versioning
- Product support
Now, what are these constraints that I'm talking about? Let's delve deeper into each of the above concepts and see how decisions may differ between IT departments (ITDs) and ISVs.
Technology Stack
ITD: I need to choose a single technology stack to host my solution starting from disk, to hardware server, to operating system, all the way to the middleware stack. I can choose the exact hardware-software combination that works best together. I can pick a technology vendor that offers me the best price and solution.
ISV: I need to support multiple technology stacks as my customers each have investments in their own choice of technologies. My customers use a wide array of hardware and supporting software, and my product needs to be able to run on them. My customers each have their technology vendor of choice, and I need to be able to support their choice of vendor.
Systems Architecture
ITD: I am a big organization with serious SLA demands, and I know that I need to architect my product in a distributed design, with server clustering, load balancing, and disaster recovery strategies. Or, I am a very small organization, and I know that I need to architect my product such that it is lightweight and runs on limited hardware, since I cannot afford more than that and my SLA demands are not onerous.
ISV: My customers range from very large organizations with IT departments of thousands of people, to very small organizations that barely have a functional IT department. My product must be able to support extreme High Availability with plenty of redundancy to meet crucial uptime for my largest customers. My product must also have the ability to be implemented on a limited scale using open-source technology in order to minimize licensing and deployment costs.
Customized Business Functionality
ITD: I know all my business requirements during the project, and I am designing the solution to meet these requirements. I know all the external systems to which I need to integrate, and I can design the solution to interact smoothly with the business interfaces of these systems.
ISV: I know the core requirements for my product that are applicable for all my customers. However, aside from the core requirements, my customers have varying different needs that need to be served by the product. Since most of these needs are not known during the development lifecycle, I must design my application to be highly configurable, with the ability to to plug in custom code into well-defined integration points.
Software Versioning
ITD: The product that we are designing is for a very specific deployment within the organization. While we will have multiple code streams in our SCM repository, we will only ever have the most current, stable release live in production, and so we do not need to actively maintain multiple code streams.
ISV: We have many versions of our product, with customer deployments on all versions. We need to make decisions on which support streams to decommission, and which ones we need to maintain, based on an analysis of our ongoing maintenance costs for each support stream.
Product Support
ITD: Our organization is our single customer, with one deployment of our product. Our Helpdesk staff provides support of our live environment to our end users. If they find what appears to be a product defect, they will escalate the issue to the development team.
ISV: We have many customers, all using the product in different ways, with different configurations. They use a multitude of supporting technologies, including a variety of hardware and operating systems. Our support team must have the skill set to deal with all these technologies, as well as understand how the product is customized at each customer site. In addition to the 1st line support team, there is a 2nd line support team that can analyze problems in more depth in order to ascertain whether there is a defect in the product. Finally, the 3rd line support team in R&D fixes product defects and releases patches.
---
Of course, any particular ISV or ITD may differ somewhat from the above scenarios. The strategies involved in an ITD may overlap with those of an ISV, but for the most part, their core decision making will be based on very different criteria.
Software Versioning
ITD: The product that we are designing is for a very specific deployment within the organization. While we will have multiple code streams in our SCM repository, we will only ever have the most current, stable release live in production, and so we do not need to actively maintain multiple code streams.
ISV: We have many versions of our product, with customer deployments on all versions. We need to make decisions on which support streams to decommission, and which ones we need to maintain, based on an analysis of our ongoing maintenance costs for each support stream.
Product Support
ITD: Our organization is our single customer, with one deployment of our product. Our Helpdesk staff provides support of our live environment to our end users. If they find what appears to be a product defect, they will escalate the issue to the development team.
ISV: We have many customers, all using the product in different ways, with different configurations. They use a multitude of supporting technologies, including a variety of hardware and operating systems. Our support team must have the skill set to deal with all these technologies, as well as understand how the product is customized at each customer site. In addition to the 1st line support team, there is a 2nd line support team that can analyze problems in more depth in order to ascertain whether there is a defect in the product. Finally, the 3rd line support team in R&D fixes product defects and releases patches.
---
Of course, any particular ISV or ITD may differ somewhat from the above scenarios. The strategies involved in an ITD may overlap with those of an ISV, but for the most part, their core decision making will be based on very different criteria.
No comments:
Post a Comment