Class of Solution Dilemma

PRI 130-30.002 Class of Solution Dilemma.doc Version 002 08 August 2001 Page 1

Class of Solution Dilemma Business and technology views influence the decisions needed to select commercial software

products versus development tools for in-house development

Jay van Zyl Rubico, South Africa

Summary: Businesses that operate in local or global economies all face the challenges of automating their key value-creation and product producing processes. The product producing software companies have effectively organised themselves around the key needs of these businesses. Some processes are fairly easy to automate when the requirements are clearly defined and shared amongst a wider customer base. The reality around differentiation is that no two organisations should be the same when it comes to the key value proposition of their offerings. Differentiation might be achieved through better pricing, more innovative customer facing processes and quality of products, as examples. This notion has caused many product selection problems and produced a multitude of solutions that are normally methodology based. Business and technology groups have different drivers when selecting commercial off the shelf (COTS) based products versus the development of software products from the ground up. This paper presents a model that can addresses the dilemma that exists in this problem space, where suppliers of software products and users of software products, both have problems in effectively matching the business requirements to software products. Software products that are needed to fulfil this need, can be classified and selected, based on their key strengths and weaknesses without increasing risks. A model is presented that can be used to assist in the selection of a software solution that encompasses architecture, COTS product requirements, and tools that deal with assembly. It is presented as a continuum whereby users of the model can use key drivers most suited to their environment to make a product selection.

1. Introduction Businesses that operate in local or global economies all face the challenges of automating their key value-creation and product producing processes. The product producing software companies have effectively organised themselves around the key needs of these businesses. Some processes are fairly easy to automate when the requirements are clearly defined and shared amongst a wider customer base. The reality around differentiation is that no two organisations should be the same when it comes to the key value proposition of their offerings. Differentiation might be achieved through better pricing, more innovative customer facing processes and quality of products, as examples. This notion has caused many product selection problems and produced a multitude of solutions that are normally methodology based. Business and technology groups have different drivers when selecting commercial off the shelf (COTS) based products versus the development of software products from the ground up.

A COTS product is defined by the SEI as a product that is sold, leased, or licensed to the general public, offered by a vendor trying to profit from it, supported and evolved by the vendor who retains the intellectual property rights, is available in multiple and identical copies and is used without modification of the internals.

Section 2 presents a solution selection model that can be used to select the correct software solution based on certain criteria.

Section 3 provides an overview of the way in which rigidity and flexibility have changed the way the world looks at software.

Section 4 shows that there are two dimensions involved in any business when decisions are taken around information technology related products.

Section 5 shows the different dimensions when finding the correct solution for the business problem under study.

Section 6 gives an overview of how learning affects the decisions that are taken with regards to the selection of products.

Section 7 closes off by discussing some of the extended drivers that are present in this concept.

2. Introducing model Major shifts took place the last few years in how consumers look at and use software products. One of these shifts is the move towards ‘customerization’. Customers want and need products defined and built in a way whereby they have full control over the features that is delivered.

2.1 Customerization

When dealing with satisfying customer needs through products, there are essentially two dimensions to consider namely; the amount of customisation required for marketing and operational implementation.

Class of Solution Dilemma


Operational and marketing customisation is not required if a product is standardized. But, when products are highly focused on delivering unique customer value and deals with the customisation of both marketing and operational areas, a different set of drivers are needed for the business.

Figure 1. Routes to customerization [Wind]

Customerization [Wind] is the focus change from being seller centric and to become buyer centric. Mass customisation only caters for the ability to respond to buyers within certain dimensions where personalization deals with the exact delivery to the buyer.

When selecting products in the customerization space, require a different set of drivers. The class of solution dilemma exists as the sellers and buyers are trying to find the match between what is needed and what can be supplied. The focus here is on software related technology.

2.2 Class of Solution selection model

The solution selection model separates the essential dimensions needed to make decisions about process implementation solutions. There are two dimensions that need to be understood to get a clear picture of the decision areas:

? ? Business View: this dimensions is normally the originator of the selection process. The core business drivers are translated into specific information technology requirements.

? ? Technology View: this dimension ensures the correct fit of the technological fit of the selection that needs to take place.

? ? Packaged Applications Approach: this is normally a strategy to purchase products that are pre-built and tested already, and thereby affecting attributes relating to risk of implementation.

? ? Development Tools Approach: this is selected based on the selection results as defined in the application selection process. The high levels of flexibility obtained by this strategy are needed to implement unique requirements.

Figure 2. Class of solution selection model

Each of the dimensions presents a number of factors that influence decisions to be taken about an approach. When working with the model it must be understood that there are only two ways in which organizations can thrive, namely [Porter]:

? ? Companies have a strong differentiation strategy.

? ? Companies provide low-cost alternatives to existing products.

3. Problems in automating processes Organizational behaviour in order to achieve differentiation has been the centre of focus for many years now. This behaviour presents many challenges in that each organization, or group of people, will have their own set of values, norms, business practices, strategies, tactics and target customers, to mention a few. Each of these contributes to the immensely difficult task of automating all of this in order to achieve optimal performance.

Software has been used to automate these processes. Human interaction and consensus amongst groups have been the fundamental influencers in performing this task successfully. In building software systems engineers are faced with the realities of the currently available tools and mechanisms to construct complex interacting systems.



3.1 The problem with rigidity

The intellectual stamina required to construct these large systems have forced complex architectural designs. In order to provide the automation capability of processes, fixed semantics have been designed into the underlying technology used to perform this process.

Available technology is researched and the most basic characteristics around business risk and product deployments are considered amongst the many. Principles around the concept of parameterisation, repository driven, and rules based systems descriptors might prove to be too complex to implement in itself.

3.2 The problem with flexibility

Flexibility on the other hand describes the belief that any audience with minimal information can alter the behaviour of software systems. The reality is that, the more flexible, the more options exist, the more difficult it will be to alter the system.

The entire software industry is focusing, in one form or another, on the ability to provide flexibility in order to solve problems quicker and easier.

3.3 Balance

In order to have a complete view of the software problems space, the issues around a balancing act must be looked at. When does one buy a piece of software that was built by someone else for mass-market consumption, and when not? The separation continuum presents drivers that relate to typical selection criteria, but each organization will have its own set of drivers that will need to come to the fore.

4. Decision dimensions These dimensions deal with the different views that influence the drivers and importance of the solutions required. If a business is strongly focused on business model differentiation then the business view will have more influence. If the organization differentiates by using technology, then the technology view will have more of an influence.

Figure 3. Class of solution selection model showing the three OPM perspectives overlaid

[Warboys] presents a model called the OPM (Organizational Process Modeling) method that deals with the separation of social and technical aspects in organizations. The Social Perspective describes business developments that include the development of new markets and changing regulations for example. Technical Perspective is concerned with technical developments of IT systems that include software development and the use of other technologies.

The OPM method is concerned with the overlaps that exist between the social and technical perspectives called the Process Perspective. This perspective deals with the ways in which particular functionality can be described in relevant business terms. Terms could include the aspects of a system that normally causes those unforeseen delays because of misunderstandings.

The dimensions of the model as presented in the solution selection model section are overlaid over the three perspectives of the OPM method. It was found that there are not only the three perspectives, but also four different dimensions that influence the ability of technology and business to evolve separately. The following sections will tackle these individually.

4.1 Decision drivers

The Software Engineering Institute released a technical report called, An Activity Framework for COTS-Based Systems in October 2000 outlining some of the primary criteria when selecting and using COTS-Based products in the systems delivery life cycle. Even tough the Class of Solution Selection model does not explicitly refer to the evaluation of vendors and sub-contractors, these criteria need to be included in any selection process.

The following table presents some of the macro drivers that need to be considered when looking at this approach:



Drivers Consideration

*Marketplace Products supplied by various vendors have specific implementation, licensing and deployment capabilities.

*Architecture and Design

COTS-based products used must operate within the assumptions of the intended architecture – transactions, connectivity, scalability, etc.

*System Context Where will the components be used and under which conditions.

Assembly The act of composing many different components supplied by various vendors.

* = COTS based development

4.2 The business view

Information technology as a primary driver of business model implementation must be understood in order to run a modern business. It brings with it the issues around the problems presented above. What are the drivers in the business model of the organization selecting technology? Can these drivers be translated into physical criteria for obtaining the right kind of software product?

Business solution providers normally focus on the business view for decision making. It is expected that the business model of the organization is understood and translated into a technology offering that is most suited.

4.3 The technology view

The drive towards “core business” has brought with it the business specialization. Each product used during the automation process needs to be carefully integrated in the greater whole, the organization. The technology view is about using certain specialized products and bridging the gaps with another set of products.

Technology or platform solution providers normally focus on this view. Architectural solutions are targeted differently depending on the type of customer. If the customer is expecting to leapfrog its competitors with innovative technology then the risks in this process must be analysed. If a certain technology product has become a de facto standard or a gorilla [Moore, 1999] then the selection process is a lot less complex. Complexity is less because strategy and market drivers determine selection criteria rather than technology excellence.

5. Separation dimensions Time-to-market pressures have forced organizations to re-look at their strategies when deciding on automation of processes, architectures and management tools. Ideally, commercially available software products should be bought and only changed if an assembly process could not materialize required functionality. It is apparent that

products meant for mass markets cannot solve many of the specific business needs, hence niche product providers and custom software development efforts.

Two key concepts must be understood when dealing with these dimensions namely; functional and non-functional requirements.

5.1 Separation of concerns

Horizontal separation is concerned with the separation of how the user interface is independent of the connectivity and in turn separate from the business logic and data access. Vertical separation is the layering needed to implement platform elements separately from the higher levels of abstraction needed at application levels.

Figure 4. Separation continuum of systems

Each dimension deals with a specific concern regarding the selection of a solution. The separation continuum is used with both packages application and development tool approaches. It will enable the selector of products to concentrate on the most important elements that were defined. One such element could be integration, where different products deal with integration differently depending on the side of the one’s looking at i.e. visual or non-visual.

5.2 Packaged applications approach

Pre-developed software products come in many forms and shapes and address most of the software problems a typical organization will ever encounter. Software vendors that build these products need to ensure that there is a market wide enough in order to reduce the development costs when features change, and to ensure maximum sales of a standard product.

Organizations that have standard, non-core processes that are fairly common and based on some best practice are easily automated by a package. The challenge comes in



when this process is non-standard and requires major modification in order to work in the intended environment. Is it cheaper to change the product to fit the process or to change the organizational system to fit the software? This is the crux of the decisions that will need to be taken about any form of pre-written software package.

It has become apparent that the selection criteria is directly related to the amount of pain already experienced in the organization. If there is a history of failed development projects, then the packaged applications approach seems very relevant.

When software products become commoditized, and specific industry leaders emerge, the process not to change the organization becomes stronger and stronger. The term gorilla [Moore] is used to describe the leading products in a particular space. It does not just apply to packages applications, but to the platforms that are used to create these.

5.3 Development tool approach

What is more difficult, to develop enterprise strength software products, or to change the processes and people that operate those processes? This question is used often when looking at using development tools for building software for in-house or commercial software product development.

Differentiate or die [Trout] and Living the fault line [Moore] describe the essence of why organizations need to differentiate based on their core capabilities and market demand of their products and services. The problem comes in when these organizations differentiate based on their processes, process innovation, that it is almost impossible to find a standard software product. The differentiation has forced the organization out of the packaged application approach into the development tool approach.

5.4 Componentization approach

With the dilemma that exists with regards to the, decision to buy a packaged application or to develop software, another paradigm is needed. Component architectures are normally presented using tightly coupled architectural design principles, where loosely coupled architectures are needed to facilitate a practical hybrid approach.

Platform architectures have emerged as gorillas in both the component and web services markets. The ability to use functionality from a diverse set of software assets that are exposed as either components or web services

present many opportunities for organizations to realize the ability to have their unique requirements satisfied without development. The notion of assembling business functionality from pre-built components still presents many challenges.

Standards of interfaces, data ownership and ability to change behaviour of components are all very real in realizing any form of off-the-shelf assembly capability [Rakic]. COTS-based products are released and built on specific architectures and technologies. This concept will influence the decision making process as the availability of other COTS products will have to be evaluated if any form of proprietary architecture is selected.

6. The learning imperative A formal approach to learning is required with organizations grappling with the continuous uncertainty when selecting solutions. Solutions change from time to time and present time-consuming projects that try to select the optimal implementation. In order to learn from these ongoing initiatives, the organization needs a formal process of learning.

Figure 5. The Learning Model

Different initiatives will yield different results over time. These initiatives would’ve had plans that were executed and checked. What needs to happen is that information about these initiatives needs to be collated into a knowledge base. Once collected, a dissection process will obtain a workable set of data that can be analysed. The result of the analysis is used to provide feedback into the organization by means of communication processes. In order to institutionalise the changes in the process, organizational structure or other aspects of the business, educational programs must be initiated. Each new concept must be learnt before using it. Integration with other concepts can only take place once the concept is understood and used.



The move towards a hybrid of packages application and development tool approaches need to be clearly managed. Even though the principles seem sound, many unforeseen challenges can derail the process of building systems from parts. The learning that is required to create a competence around this paradigm is of utmost importance. Each area of implementation needs to be planned for as per the learning model phases in order to assist with the evolutionary or revolutionary change that will be required after a thorough understanding has been reached.

7. Closure The dimension that’s not always mentioned, but that influences decisions is the human angle. Effective sales techniques have a major influence over the kinds of products that can, and will be selected. Relationships built over time that are trusting, can be more collateral than a track record in delivery of products.

Integration still seems to keep up the wide spread adoption of the concept [Boehm]. There are many challenges in the integration of the various COTS-based products supplied by different vendors. Transactional and data ownership qualities normally provide many hick-ups when trying to do off-the-shelf based integration.

8. References [Porter] Porter M., (1998), Competitive Strategy: Techniques for analysing industries and competitors, ISBN 0-684-84148-7

[Wind] Wind Y., (2001), The Challenge of “Customerization” in Financial Services, Communications of the ACM, June 2001 – Volume 44, Number 6.

[Warboys] Warboys B.C., Greenwood R.M., Kawalek P., (2000), Modeling the Co-evolution of Business Processes, Systems Engineering for Business Process Change, Springer Varlag Publishers, ISBN 1-85233-222-0

[Stevens] Stevens M., (2001), Extreme Management: What they teach at Harvard Business School’s advanced management program, ISBN 0-44652-321-6

[Chan] Chan Kim W. and Mauborgne R., (1999), Strategy, Value Innovation, and the Knowledge Economy, IEEE Engineering Management, Fall 1999

[Trout] Trout J., Rivkin S., (2000), Differentiate or Die, Survival in Our Era of Killer Competition, Wiley Publishers, ISBN 0-471-35764-2

[Moore] Moore G. A., Johnson P. and Kippola T., (1999), The Gorilla Game, Picking Winning in High Technology, Harper Business Press, ISBN 0-88730-957-7

[Moore] Moore G.A., (2000), Living on the Fault Line, Managing for Shareholder Value in the Age of the Internet, Harper Business Press, ISBN 0-88730-888-0

[Boehm] Boehm B., Abts C., (1999), COTS Integration: Plug or Pray?, Computer Science Department, University of Southern California.

[Rakic] Rakic M, Medvidovic N., (2000), Increasing the Confidence in Off-the-Shelf Components: A software connector-based approach, Computer Science Department, University of Southern California.

[Obemdorf] Obemdorf T, Bownsword L, Sledge C.A., (2000), An Activity Framework for COTS-Based Systems, Carnegie Mellon University & Software Engineering Institute, CMU/SEI-2000-TR-010

?

Documents

Class of Solution Dilemma