Solutions and Products

Problems can be solved with people, functions and products. A product usually offers several functions that play an important role in solving a problem. Products are usually part of an overall solution, but are not usually the overall solution themselves.

Business and IT

Business is an organization that conducts a business activity and offers products on the market. IT is the digital infrastructure that should support that business activity and create new product opportunities. Business has an interest in ensuring that IT is aligned with business requirements and improves its own competitive position. After all, digital data makes many things possible that are difficult or impossible to achieve in the analog world. As simple as this sounds, it is just as complex in reality. For data to be exchanged between different systems and programs, standards are needed.

IT products to implement business requirements

To implement this, products are needed that offer the required functionality. They should be fit for purpose and cost-effective. To do this, they must support the most common standards. Products can be developed in-house, purchased or obtained as a service.

What is a product?

A product is an overall package consisting of functionality, customer benefit, customer experience and cost. These four cornerstones also largely determine the potential customer base. In the case of in-house development, the customer is the company itself. The decisive factor for the customer is not only the functionality when the development is completed or the purchase is made, but the benefit over the planned useful life. The customer benefit is objectively determined by the totality of the performance characteristics of the core product and the associated contribution to the customer's problem solution. The performance characteristics include not only functionality but also implementation. Functionality alone is no guarantee for a customer-oriented and competitive customer experience. This relates to the customer's subjective experience from product consultation - through purchase and commissioning - to the end of product use. In addition to user-friendliness and integrability, this also requires customer service that is efficient for the customer. This helps the customer with product-specific problems and ensures that the customer can use the product as planned during its service life. Product development does not end with the availability of the product, but is an ongoing process.

Product: Build or buy?

Not every company wants to or can build its own IT solutions. Building a product only makes sense for those subareas for which no suitable solutions are available on the market. The assessment of suitability is subjective and depends on the respective requirements of a company. Desired functionality, price, product characteristics and product availability are some of the criteria. If a company is not itself a vendor of IT-based or even IT products, in-house developments make sense at best primarily in two areas: (1) support of internal processes, and (2) interaction interfaces with specific functionality with third parties. 

Interaction interfaces with third parties are needed on one hand for one's own web presence and on the other hand for one's own offering, that is made available digitally. If you are building your own solution, you must support standards towards the outside, while internally, i.e. within the product, there is a lot of design freedom to efficiently implement the desired functionality. Custom development only makes sense if a clear added value is created compared to commercially available solutions, thus improving one's own competitive position. Custom development can create a substantial competitive advantage that would otherwise not be possible. Both, custom developments and commercially available products create dependencies.

In-house developments

In the case of in-house developments, it is the know-how about the respective in-house developments in terms of architecture and product development. This is a company dependency on its own organization and its own resources. Even if an in-house development is largely completed, a sufficiently large team must continue to exist for the in-house development so that the know-how can be maintained. An operationally usable product must also be maintained and further developed. Otherwise, due to the platforms, frameworks and libraries used, the technical status quickly becomes obsolete, usability in conjunction with external resources is no longer guaranteed, and the competitive advantage is constantly diminishing. In addition, due to a lack of activity, know-how is lost, which has a negative impact on the value of in-house development and the maintenance of the associated functionality. Only people with limited understanding fail to grasp that software development based on available platforms, frameworks and libraries is never complete. Because these platforms, frameworks and libraries evolve or become obsolete. In the process, among other things, functional and security-relevant vulnerabilities are also eliminated, which in turn have a direct impact on in-house development. These are dependencies that must be taken into account for every in-house development, especially of complex systems.

Commercial products

In the case of commercially available products, the vendor of the product is subject to all of the foregoing for proprietary developments, plus the customer is subject to the vendor's respective implementation, business policy, and product policy. There is no guarantee that a vendor will continue to develop or offer its products in the same form in the future. There are no guarantees that the vendor will fix functional or security vulnerabilities and malfunctions. Nothing prevents the vendor from making its products or certain functionalities dependent on the use of its cloud offerings. That's what's happening in the market right now, and it's having a direct impact on the IT structure at the application and data level, on the organization and on the processes. On top of that, the pricing power is with the vendor and this is significantly increased by forcing them to use their cloud offerings. The effort for customers to change vendors is constantly growing, and with it the dependency.

The agony of choice

Business must clearly communicate its expectations and requirements, particularly with regard to functionality, availability and security, so that a robust requirement document can be created. Depending on the area of IT in which a procurement is pending - infrastructure, communication or application - the requirements are different. As a company, you must always ask yourself which assets are strategic. This applies to all areas of IT. As the well-known and world-renowned data center, cloud, network and application expert Ivan Pepelnjak clearly states, for the network area, for example, this classification is decisive for whether you operate something yourself or not and whether you invest primarily in commercially available products that are as feature-rich as possible, or primarily in your own people. The same applies to the operation of one's own IT infrastructure and business applications. Business and IT interact with each other. If the vendor is weighted higher than the product for a product decision from the outset, this also rules out a best-of-breed approach from the outset. This in turn has an impact on IT and on the business.

The configuration and implementation effort should not be underestimated. This applies to all areas: Infrastructure, network and applications. In the case of the latter, it affects not only IT and its people, but also the users. In addition, there are often company-specific enhancements for business applications, and these are not limited to on-premise installations. If the existing organizational structures and processes in a company are part of the competitive advantages, they are a strategic asset. To ensure that this is not lost, there is no getting around the need to adapt business applications to one's own requirements. This is nothing out of the ordinary, and it costs money. This effort is often underestimated. Especially the fact that these adaptations must also be maintained, supported and further developed.

Two examples: Salesforce started with the slogan "No Software" as a CRM application. Today, Salesforce sees itself as a platform because Salesforce cannot be adapted to operational requirements (organization and processes) without additional custom development by the customer. And for a platform you need tools and developers. The tools can be found here. And your own development effort comes on top of the cost of Salesforce. It's the same with SAP. But unlike Salesforce, SAP has never claimed that it doesn't need any additional effort. The tools can be found here. The situation is similar with Microsoft and many others.

Partial or complete custom developments are the rule rather than the exception for business-oriented applications, for web applications and for many production controls. The reason being that customer requirements are individual and therefore many vendors prefer to see themselves as platform vendors rather than pure application vendors. as the addressable market is significantly higher. The extent of custom development is defined by the configurability of an application and by the business requirements.

The requirements specification must take into account the expected business development and the expected development of in-house IT for the first five years after go-live. The evolution of environment of the area for which a solution is needed must also be included. IT environments are becoming increasingly complex. The same applies to commercially available products and platforms.  These must be able to be integrated into the existing or future IT environment at all levels. If you don't know what you need, what you want and how you want to use something and for what purpose, then you face an uphill battle.