Taxonomy of System Attainment Methodologies - OR - Configure or Program? : that's the Question!

Taxonomy of System Attainment Methodologies

		[Building or Acquiring]

Available on this page:

Overview




Overview		Another one of the questions that is frequently asked of the Artige staff goes along the lines of "what is the difference between programming and configuration?". So we decided to write up a response and post it as an article for all to read. The title of this article is a fancy way of saying that there is more to this question than simply acknowledging the fact that there is a difference. Both terms typically bring along the questioner's predilection of enterprise systems, the time and money it takes to build them. Since this matter is at the heart of many of the products that the Artige Company offers, it is worthwhile to explore these issues at some depth and see if this conundrum can be reconciled.

		One of the typical selling points made by vendors of real time data collection systems is that their systems are "configured", rather than programmed. If you ever configured one of these systems, you will start wondering what the benefit of configuration was? Regardless of tools available to the system builder, the size of the system and its large volume of minuscule details will play a major part in dictating the size of the task involved. After all, automation will not happen without a person designing the system. This article will investigate the methods that are available in building a system and explain what each method provides the system builder.



Basis		What do we mean by attaining a system? The assumption is that an enterprise has a need to automate a business process, whether it be a manufacturing task, such as formulating and casting die casting alloy ingots, or a service task, such as processing an new insurance applicant. The desired system is not yet available for the enterprise to use, so the enterprise must attain the system in order to automate the process and reap ROI benefits. That is where the system builder comes into play. This person will buy or build the system, using whatever resources are available in the most efficient manner, in order to generate as large an ROI as possible. This article will define and analyze the different methods that one can use to attain a system.

		Definitions

		It would be a good idea to understand what the Artige considers these terms to represent, before we go off and analyze the difference between programming and configuration.

		Programming:	Setting the order and time for planned events, sequencing instructions in order for an automated device to operate as desired. Programming relies upon an abstraction of real world devices and actions through the use of a model and a corresponding language in which the model can manipulate the real world devices. Preferably, all aspects of the devices operations should be made available through the model and language.

		Configuration:	Is a collection of objects required to execute a particular project, represented as a list of parameter-value pairs when taken as a whole can represent how a system should be constructed and / or operated.

		Urban Legends

		The question of programming vs. configuration seems to have a few prejudiced notions going for it. We will list some of them here in the "Urban Legends" section of the article. Hopefully by the end of this article you will be able to walk away with a better understanding of how an enterprise system can be built, and where some of these ideas come from.

		Which is better?	The question that we are pondering in this article has also been proffered to us as "which is better: configuring or programming?", with the answer presumed to be "configuring". Our answer is (as always) "it depends". As will be described below, there is a difference in effort and resource consumption, and you will get back what you put into the project.

		Reusability	There is an assumption that configurable systems are reusable and can be rapidly replicated when a new project comes along. The silent part of this conjecture is that a system that was programmed cannot be replicated. The issues of replicating and reuse have nothing to do with the system building methodology, rather with how the system was deployed and the toolset available to the system builder.

		Build or buy?	Most people would not build an automobile; they would rather go to an automobile franchise outlet and purchase one that was ready-to-run. The same applies to enterprise software, right? Again, it depends! If you have no desire to obtain a strategic competency through the use of IT systems, then you might as well buy an off-the-shelf system [more on strategic competency can be found on our OR consultancy webpage, click here to read it]. On the other hand, if you wish to obtain a strategic competency, then building your own system will make sense. Another situation would be where your functionality is not available off the shelf. In that case you will have no choice but to build your own.

		Flexibility	It has been said that flexible systems can only be obtained through programming a system you built yourself. We at the Artige Company have seen configurable systems that are quite flexible. What is missing here is a context for the term flexibility. This is another term that is affected by the level of granularity. A flexible system is one that can create different outputs based on an expected range of inputs. This would be considered a coarse level of granularity. Another type of flexibility lies in the ability of the system to have features added and removed. This would be considered a finer level of granularity.


		When the system is designed, the system builder would need to know which criteria is most important in order to attain the system in the most efficient manner.



Analysis		The Strength / Weakness approach will be used here to evaluate the differences between the different methodologies. Note that one's strength is not necessarily the other's weakness.

		Strengths that Configuration Offers

		List oriented	No need to learn a logic processing methodology or programming language.
			Assumes that person with primary school education can manage a list.

		Hides operating details of the system	Lets a person with minimal knowledge manage a more complex system using metaphorical abstractions.

		Weaknesses Inherent in Configuration
		System parameters must be managed using a list	Presumes that the system parameters can be managed using a list [this can be a mighty BIG assumption].

		Only parameters that are listed can be managed	Unless every feature of the system is listed, there will be features of the system that cannot be managed through configuration. Typically, it is impossible to catalog every feature of a system, unless the system is extremely small and self-contained. Most likely, the 80/20 rule will be invoked.

		Strengths that Programming Offers
		Variety of automation methods can be deployed	Many automation models are now available to the system design team, allowing the team to select a methodology that best matches the system characteristics.

		Access to nearly all aspects of the system	As long as the system provides access points, the system designers should be able to manipulate those points through a program.
			Additional access points can be made available when they are required, as long as the client is willing to obtain the resources to create the additional access points.

		Weaknesses Inherent in Programming
		Inexact science	More than one way to accomplish the same end result, analogous to a hysteresis loop.
			Not even an exact methodology to perform a single automation task.

		Non-intuitive	Requires "best practices" to sort out efficient method from variety of methods available.

		Model-based	Successful programmers must possess the skill to associate real world objects and actions into metaphorical objects and events and be equipped to manipulate them in a figurative sense. This is not a skill all people possess.

		Resource bound	Availability of people and their skills, as well as hardware and designing tools plays havoc with project planning.
			This means the complexity of executing a programming task is not linearly related to the complexity of the system being constructed.

		Not Addressed in the Strengths / Weakness Analysis

		The above methodologies are related to building your system. If building a system is not desirable, purchasing one might be. Below are system types that can be purchased.

		Size of task	Larger systems require more effort and resources.

		Who performs the task?	People are required regardless.

		Loss of core competency	No differentiation between companies if they all deploy the same systems in the same manner. This could lead to loss of core competency and strategic breakdown.

		Other System Attainment Options

		So programming is too much work and configuration is still not good enough. There is still another pair of options one can look to.
		Turn-key system	A turn-key system is delivered ready to run, for a one-and-only instance. Hence the concept where all one has to do is "turn the key" and start the system.
			Configuration and /or programming is optional, and provided for reasons beyond operating the system as originally defined.
			A turn-key system is a custom system. Many units of the same turn-key system can be delivered, but they would be pretty much useful for only the same purpose.

		Appliance	An appliance is a ready to run device that is manufactured for general consumption.
			Some portion of the appliance may be configurable; otherwise it might not have been possible to sell the same appliance to multiple parties.
			Other enterprises and individuals will purchase the exact same unit; although not necessarily for the same purpose you did.

		Strengths that Turn-Key Systems / Appliances Offers

		Ready to run	The benefits of running the system or turning on the appliance should be realized immediately upon commissioning.
			Also known as plug and play.

		Nominal maintenance requirements	Quality of appliance plays a string factor in its maintenance.
			Complexity of the turn-key system has impact on it maintenance requirements. Can be offset by outsourcing maintenance to provider of the turn-key system.

		Weaknesses Inherent in Turn-Key Systems / Appliances

		Cost	A turn-key system is custom designed system and will be more expensive to purchase than the individual components.

		Fixed functionality	An appliance may not have all the features that the customer desires, and is rarely extensible.
			A turn-key system will be delivered with predefined functionality. Extensibility would need to have been defined ahead of delivery.

		Preliminary design	A turn-key system must have all of its features declared during contractual negotiations.
			An appliance has had its features determined through marketing methodologies, in order to address as large an audience as possible.




Project Management		Note that specific programming methodologies have not been discussed in this article. It does not matter if the system is built using conventional means, or if RAD, extreme programming, object oriented methods, XML, web services, high performance teams, CORBA / DCOM, skunkworks were used at all. These technologies are all means to accomplishing an end, that of building a system through programming. The same goes for purchasing a system, no differentiation was made on whether the system was bought from a well-known vendor of high repute, if the vendor was selected from a pre-approved or consolidated list, whether scientists from NIST should have been involved, and what the tax implications between leasing and buying the system are. These are factors associated with purchasing a system.

		The reason none of these matters (plus many, many others) was discussed in the context of attaining a system, is that they are orthogonal to the successful implementation of the enterprise system. Each factor may in itself please one party over another, and may provide certain individuals with leverage over others within an organization. The question being addressed is how will the attained system meet the needs of the enterprise and provide the desired processes in a cost-effective and efficient manner, plus allow the enterprise to react to the ever-changing business environment. In order to focus on the processes, a process-oriented person must manage the attainment.

		In most circles, this would be considered to be project management, and that person considered to be a project manager. It is project management that determines the success of an implementation of an enterprise system, no matter whether the system was programmed, configured, turn-key or an appliance. A person must collect the requirements and compile them in the context of the enterprise's mission statement, so that the business processes affected by the system operate as dictated by the enterprise's way of life. Some of the strengths that project management brings to the table are:

		Effective Communication

		One of the reasons cited most often in a enterprise system success has been effective communication, typically through project management. This includes fomenting a common vision on the project's goals to all parties involved; customers, management, and staff members . Methodologies, performance against schedules, even budget spendouts must be constantly communicated for a project to be successful. Meting out information on a need-to-know basis is a sure means to poor system attainment.

		Traditional Project Management (control)

		Good old fashioned project management is the best way to insure project success. The project manager has to trade off time, cost and functionality against the resources he has on hand. This will never change, irregardless of teams, tools, marketing desires, lifecycles, etc. These side issues cannot detract from the need to guard against feature creep, cost overruns and schedule slides.

		Documentation

		Contracts, functional specifications, system descriptions are the project manager's best tools to attain the successful system. Documentation is a means to start building understanding and comprehension, and should not be seen as the means to prosecute the customer. And it is the process of documenting the project requirements that builds comprehension, not the generated documents themselves! Which is why as many team members need to be involved as possible from the start.

		Change Control (plan for change)

		Smart project managers recognize that change must be dealt with, and deal with it in a manner that all parties involved are satisfied. The most important truism that one needs to know is that change will happen, so one will need to compensate for it. Ignoring change, especially hiding behind contracts and specifications, is another sure sign of doom.



Conclusion		It is human nature and rational to seek the simplest, cheapest, fastest solution. It is irrational for knowledgeable people to act against their best judgment, yet time and time again managers procure systems that do not live up to the claims made by the vendor or the system builder. What this analysis points out is that many options are available to the system builder to attain an enterprise system. However there are just as many means of talking shortcuts, plus many sources of information that can be misinterpreted, that poor system building decisions can be made.

		The best defense against a poor decision regarding the attainment of a system is to spend the time to understand the systems requirements and criteria, know the construction and operating constraints, and synthesize these inputs against the taxonomy presented in this article. At least then you will have a basis for making a sound decision regarding the attainment of an enterprise system.




		Return to articles page	Navigate to home page

Legal

Last updated:
17-April-2005 04:08z