IT Process Design Appraisal Research from the Artige Company

IT Process Design Appraisal




		If you have any questions concerning our article comparing TQM concepts with agile methodologies for software development, or wish to make any comments, please feel free to send a message to us at quality@artige.com.



		If on the other hand you wish to engage our services and would like to apply these principles and our experience to helping your firm increase its profits, then please send a message to sales@artige.com or call us at (1) 717-354-5541, and one of our representatives will be happy to discuss your needs.

	Available on this page:		Overview		Background		Automation
			Methodologies Defined		Methodologies Compared		Conclusion




Overview		This article is an outgrowth of our work on the instructive Artige Quality Matrix, which is where we compare various business design and quality related approaches to each other. We enjoy taking the time to explain the difference between the various process design methodologies and quality approaches. Our article on Business Process Design Appraisal (BPDA) goes into depth to define the process design methodologies, show where they were derived from, maps them against a set of criteria, and then proceeds to compare them to each other. Since that work has been published, we have been asked follow-up questions along the lines of "what is the difference between (take your choice): Agile software development; CMMI: RAD; RUP; XP and those quality approaches of TQM; Kaizen / continuous improvement; ISO 9000; reengineering; change management / BPR; six sigma; lean manufacturing". We will also tackle the polarizing issue of "is agile programming cowboy coding". Hint: note the reference to Kantian principles during the discussion on automation.

		It would make sense we would be asked that since we at the Artige Company spend a fair amount of time creating software products and executing IT projects, along with our operations. So we decided to handle this question just like we did with the original business process appraisal research and write an article on IT Process Design Appraisal (ITPDA) and post it as an article in a living document for all to read.

		The observant reader will note that this topic is just an extension of the material we discussed in the BPDA article. At the level we treat the material, there is no real difference between the systems that business or IT processes are based upon. It all stems from General Systems Theory. This also means that this article will continue to use the reductionist tools of scientific analysis, plus rely upon mathematics for modeling, natural laws of physics for constraints, Kantian principles for guidance and continuance, in order to provide balanced and equal comparisons. This article will refer to the BPDA article quite frequently, to save space from not re-explaining the terms and methodologies here. It would be in the reader's best interest to study the BPDA article prior to reading this article, in order to see what our approach to the analysis is and see our definitions for processes and system related terms.

		This analysis is intended to be unbiased, otherwise it would be worthless. Note that the Artige Company Services Division does not have any allegiance to certain software design practices when working with clients in our consultancy. Our own products are managed and we have a predefined process that we consistently use, but that process serves our own situation, criteria and business model. We would not presume to impose our specific practice criteria on others.



Background		Process design has its roots in operations research (OR) and statistics, regardless whether the process will produce physical items such as those generated through manufacturing or perform a useful task, such as those delivered as part of a service. Either way it is an exercise in sequencing tasks so that resource consumption is minimized in order to maximize the expected benefit. The BPDA article showed us that a process is separated into the following parameters:

		Energy
		Distance
		Work
		Task
		Stock
		Product
		Waste
		Rate
		Lag
		Value

		The BPDA article also mapped a process into a systemic point of view. This may be obvious for those of us that work with IT systems on a daily basis, but this is a necessary step to maintain the apples-to-apples comparison. By accepting a system mapping, the alignment of a process is straightforward; the inputs are energy and optionally stock, the transformation is the work, and the output is modified stock or satisfied customers that has had work applied to them. For processes dealing with service products, the stock is not physical, but the pool of people willing to perform the desired task.

		The other point made in the BPDA article is that the task of designing a process is a process in itself. This is a second order activity, and is modeled in the exact same systemic manner. if one wishes to run an efficient and successful operation then this secondary process must be managed and not ignored or left to chance. This is one of the key tenets that Deming harps on in his 14 Points, and is what change management focuses one. In the realm of automation and IT process design, the secondary tasks are also manifest through the latest IT buzzwords of web services (SOA) and Business Process Execution Language (BPEL).



Automation		This section will define IT process design using the terms set above. This is done under the umbrella of "automation", which is essentially what differentiates process design for IT purpose vs. other process design tasks.

		As explained in the BPDA article, process design is the systemic arrangement of tasks such that one can provide stock, and energy as input and expect that a product will appear in the system output, with the expectation that the arranged tasks performed transformations along the way, with the additional expectation that the output will appear at a certain time, and that the process operator can modify the output over time based on the system feedback. Note that in a service environment, the operator and stock could be the one and same person.

		In the specific case of automation, there is a desire to provide consistent output for the same input, without the assistance for people in the process. However, many processes are unable to be completely automated, so interfaces are introduced that allow individual tasks to be passed onto human actors, or human actors provide inputs to an automated process, or where even both interact with each other.

		Yet, automation cannot be implemented without the automated processes being designed. At this point in time it takes humans to perform the automation. So IT process design has to handle two levels simultaneously. At the low level there are processes that are automated, and at a high level there are processes to implement the automation.

		Note that this definition of process design does not make any claim as to effectiveness or efficiency of the process. It just states the definition using terms where we can now compare different methods of designing a process up and running it, and see how one compares to another. At the low level we should be able to modify the inputs and the transformations and expect different outputs to appear, possible at different points in time. At the high level we can draw upon various precedents in arranging the tasks to be automated, apply them in different environments, and expect different means of accomplishing the automated process to be created, each satisfying a different set of constraints. By the way, some might recognize these precedents as "best practices". It also points out that the both the low and high level systems themselves may change their output over time, as feedback plays into the picture.

		Just like the BPDA article did, we will rely upon Operations Research (OR) principles to explain how a task or process is mapped to a system, and how systems can be decomposed into parts that can be analyzed and compared on a consistent basis. The models can also be used to discover the most efficient process, the one that delvers the most benefit under a given set of constraints. Please see the BPDA article for our usage of the OR term.

		We will also rely upon Kantian principles, as the BPDA article did, to determine how criteria would be selected for this analysis. Note that one premise of the Kantian principles is that they must be unwavering. This fact needs to be put into perspective, especially for those in the software industry, that like to use the phrase "it depends". As long as this phrase means the process being modeled will be built according to fixed criteria, then that phrase is obvious (of course it depends upon ...). However, if the phrase means that the criteria will change, then the question begs, what criteria will the change in criteria depend upon? Sounds like a second derivative if you ask us, and is a major factor in determining whether software design is reproducible or not. If there are no criteria, or the criteria can be modified at whim, then the probability of consistently executing automation projects has been diminished.

		So, what would a perfectly automated process look like? We have an example of a perfect process, the "Toothbrush Factory" in the BPDA article. There is no reason why the low level automated process would not fit that model. However, the high level design process could use an example of its own. We call this perfect process the "Happy Entrepreneur", and it is described below.

A Perfect Process		The Happy Entrepreneur

		We have a favorite example to explain how the parameters interact with each other in second level process design. Say that there is a factory store being run by one person, who happens to have limited resources. The main product of this firm is to produce black boxes that in turn manufacture toothbrushes. These black boxes are customized to meet the needs of each customer and are constructed and delivered in lot sizes of one. Just so happens that this entrepreneur has a black box maker. This black box accepts a lump of iron ore, lump of coal and a cup of water. Plug it into a power receptacle and after a period of time it will spit out a new toothbrush black box. This is a straightforward example of automation, and is already covered by the toothbrush factory example in the BPDA article.

		Now say the entrepreneur wishes to modify the black boxes being manufactured based upon different requests from the customers, type of coal that the customers are able to purchase, dental hygiene guidelines from the government, and the latest fashion fads. In other words, there are constantly changing sets of inputs to the criteria that are governing the manufacture of the toothbrush black boxes. How will the entrepreneur handle this high level process? The most effective method that results in maximum benefit for the constraint presented for every customer is to have the requirements inserted into the entrepreneur's black box at the exact moment before it is turned on to create the next customer's toothbrush black box. The method of inserting the requirements is trivial and effortless, probably some sort of mental telepathy interface, assuming that people are still involved in the process. Think it and it happens, and makes for a happy entrepreneur.

		As was mentioned earlier, the low level automation that made the production of black boxes possible was already handled by the toothbrush factory example. The high level process of directing the operation of the automation needs to be expanded, as the perfect process described above compressed a great quantity of tasks into a trivial procedure. Even ignoring the futuristic user interface, this process incorporates many sub-processes that would be needed today to accomplish the same objective.

		The main point is that today we must endure limitations on our understanding of communications and language, plus our inability to exactly determine what parameters to tweak to influence the desired outputs to take place in individual processes. These limitations can be grouped into two categories, understanding what the desired outcomes are, and then finding a way to make those outcomes happen. The Happy Entrepreneur has overcome these two obstacles, able to create processes that meet the exact needs of the customers, able to modify the processes at will to meet the ever-changing whims of the customers, all the while maximizing the benefit to both parties involved using minimal resources.

		Since the current technology does not allow us to create processes at will that meet the needs of our customers, we must find other means of accomplishing the same. These other methods are numerous in number, inefficient in satisfying customers and entrepreneurs alike, resulting in benefits that are not maximized for either party.

		Note that since we do not have a complete understanding of process design and communications, it is not possible for any one person to claim they have the one and only solution. The process design methodologies presented in this article are some of the currently most popular ones, and all of them have merit in the areas that they focus on. The system designer today would review the available methodologies and see which ones best match their working environment and customer base. This is the purpose of this article is to show what constraints they focus on and compare them to each other.



Methodologies Defined		Now we need to know what these OR related process design methodologies are, so we can see what parameters are most important to them. Below are the IT process design methodology definitions that we use at the Artige Company. The original TQM / non-IT related methodologies were already defined in the BPDA article, and will not be repeated here, especially since they take up quite a bit of room. These IT related methodologies are listed in the chronological order that they have appeared in the public domain. Note that your mileage may vary, and no one has any official definitions for all of these methodologies. Also note that the definitions provided below are not entirely descriptive of every facet of each methodology. Rather, the succinct points were extracted, focusing on the physical parameters described previously, to enable the apples to apples comparison later on.

		At this point in the article there is a need to make a differentiation between high-level and low-level processes. This will hopefully explain why everyone's favorite IT design methodology may not be listed below. Some literature refers to this differentiation as processes vs. meta-processes. The term process in that sense is confusing, and should really have had an attribute associated with the stand-alone "process" term. What these two words are referring to is the fact that systems can be used to design, build and operate other systems. This was pointed out in our BPDA article, where we differentiated between first and second order processes.

		Since IT process design is immature when compared to business and manufacturing processes, it is understandable that the processes of design and construction would be confused with each other. This article enforces the notion that these two process types are different when analyzed using General Systems Theory, and they need to be kept distinct in order to properly understand how to maximize benefit using minimal resources when automation is being deployed. In other words, the time has come for IT process design to "grow up" and be treated like any other system, else maximum benefit will remain elusive.


				Undisciplined

				This category of system design methodologies covers the fact that automated systems can be designed in an ad-hoc manner. Minimal or no planning is carried out before the automated system is actually constructed. Whatever comes to mind is deployed. The system may be modified, refactored or even completely redesigned or rebuilt, one or more times, until the system designer is satisfied, if that is even a possibility. This system may also be constructed on a physical basis, using the interfaces that are to be used by the automaton. Many times such a system construction methodology would rely upon bottom-up design techniques.

				This system design methodology could also be covered by the terms cowboy coding, undisciplined hacking, DIY, and flying by the seat of your pants.

				Waterfall

				We use this category to describe systems built on a systemic basis. Collect requirements for input, transform them using IT technologies (undefined and unrestricted) to meet the needs of the customer, test the output to verify that the customer's needs were met, and collect feedback to determine if another iteration of the design process is essential in order to meet the customer's requirements. Note that the IT technologies are defined below, and might assist in alleviating concerns about simplistic definitions. Keep in mind that process design is a high level function, and that there is no natural law that binds a process design methodology to an automation construction methodology. As a matter of fact, the task of constructing the system is one of the waterfalls. The system design is a separate and distinct function apart from construction.

				Computer Aided System Engineering (CASE) / Computer Integrated Manufacturing (CIM)

				This category of system design methodology takes a step beyond the waterfall method and attempts to automate some of the automation construction. The CASE acronym indicates that a computer will assist in the construction. That is shorthand for the output of the design process to generate some or all of the automated system. Really, is that not what computers are for? Anyway, the CASE concept was also extended into the manufacturing realm with CIM. Not just the business process, but also the actual manufacturing processes would be have their automation capabilities generated.

				Capability Maturity Model (CMM)

				This category of IT system design covers the design processes put into place by organizations that wish to monitor and grade their design activities, while deploying automated systems. The most prominent one is CMM index, which is the source of the name for this category. However, we like to group the methodologies that wish to document, evaluate and restrain their design activities into this category. The Software Process Improvement Capability Determination (SPICE) method also known as ISO 15504 is an example of another system design approach that falls under this category. At some point we will come up with a proper name for this category that does not refer to a proprietary method.

				The assumption here is that the automation design processes are systemic, and would be covered at a minimum by the waterfall methodology. This approach will minimally record and grade the design methodology used. There may be an attempt to apply some sort of metric. This is all carried out in the hope that the design process will be applied in a consistent manner, which then in turn may lead to a predictable outcome. Recall from the waterfall methodology that there is no single method to design, let alone construct the automated system. When multiple iterations are performed, the separate iterations could be executed in different and inconsistent manners. This methodology seeks to prevent the inconsistency from occurring between iterations.

				For the time being we are including the unified modeling processes in this category. This would include UML methods of RUP and EUP, what some would consider to be a heavy modeling methodology. These forms of system design methodology would include some of the CASE-like attributes of generating code as part of the design process. The unified modeling processes attempt to enforce similarity in modeling practices through the use of a modeling language. This is inherent in the name of the methodology, which includes the term "unified".

				Rapid Application Development (RAD)

				RAD is used in two contexts, so we need to discern which we mean here. One context is where a software application is generated using an existing application as the permanent host, and the desired outcomes are configured or programmed by selecting existing components and functions and linking them together. Frequently the application is created using "wizards", which have some best practices incorporated into them to point out previous methods that may be useful in the current system being designed. This is NOT the context we are considering. This type of RAD is just another IT tool that would be listed in the IT technology listing below.

				Rather, we are considering the RAD methodology that relies upon prototyping the desired outcomes that will be a result of the automation being designed. The most frequent instance of this type of RAD is where an end user is presented with partially working scenarios, and the functionality tested to see if the customer is satisfied, before the complete system is designed and constructed. This methodology is an outgrowth of the waterfall method, just that it would need to have more iterations included in it. It attempts to overcome the communications obstacle by having the customer interact with the person responsible for designing and constructing the system. In addition, the improvement in communications and understanding of the desired outcomes should result in the automated system being developed "rapidly", at least compared to a straight waterfall approach.

				Agile Methods

				This is another method that takes the waterfall approach and increases the number of iterations to execute a design and construction. It also stresses the need to communicate with the customer to insure a better chance at meeting the customer's requirements. Like RAD, prototyping is encouraged, but a different approach is taken. The customer is required to provide test scenarios that the system outcomes can be measured against in a consistent manner. The customer may also be involved in the design and construction process much more than the other methodologies, especially in running the tests at a frequent rate. One point here is that there is a focus on system construction and less time is spent on modeling. This follows Churchill's despise for planning during WWII, where he felt the value in planning was not in the plans generated, which were thrown out every iteration, but the process of the planning brought insights to those doing the planning, which were then converted into profitable tactics.


		IT Technologies

		We use this term to describe the toolkit that is available to the process designer. When a carpenter performs different tasks, different tools would be used. So, just like the carpenter who has hammers, saws and planes handing up in the toolshed, the IT system designer will have a multitude of tools available for use in order to automate a business process. A sampling of these technologies is listed below:

		C / C++
		Data Flow Diagrams (DFD)
		Database Management Systems (DBMS)
		Dynamic Systems Development Method (DSDM)
		Imperative programming
		JAVA
		Object Oriented programming
		Procedural programming
		SCRUM
		Service Oriented Architecture (SOA)
		State Tables
		Use Case Diagram
		eXtreme Programming (XP)
		XML

		As was mentioned at the beginning of this section, the number of IT design processes selected for analysis may seem small. In particularly, it may have expected that some of the technologies cataloged in the IT Technology listing above might have been a process that needed to be defined. Based on our strict differentiation between design and construction, the IT technologies that are used for construction would not fit this analysis constraint. Actually, on first pass we had merged the RAD and Agile methodologies as a single category, but separated the two only to point that their iterative focus is on different levels of granularity. Also, we need to come up with different names for these categories, which will happen once we come up with some snappy names.

		This analysis also shows that there have not been that many IT process design methodologies developed. Instead, there have been lots of ways to construct systems, just as there are many types of hammers, screwdrivers and chisels the carpenter has access to.


		Group Dynamics

		One topic that the BPDA article declined to touch upon is group dynamics. That article focused on process design using the laws of physics, so it relied entirely upon cause and effect analyses in its reasoning. However, IT process design is directly impacted by the people that execute it processes and by the people that design its processes. So, it will be imperative for this appraisal to include additional source material that does not have a direct cause and effect basis. One of the areas that IT processes focus upon is inter-personal interaction, so it would be of value to investigate group dynamics.

		Particular to the analysis between the agile methods and other methods is the size of the group. This is an easy concept to explain and there is behavioral research already carried out to support it. Plus, network theory can even be used to explain why agile methods work as they do. The idea is to break down a project into small tasks and have individuals or small groups work on these tasks. The main thrust of inter-personal interaction is to foster direct communications between those working on the project. Direct communications has been recognized as being the most efficient method to transfer data and knowledge between individuals.

		As a visual demonstration of how direct communications will only work with small groups, consider the below list of conversational routes between personnel for different size groups:

			2 Developer = 1 route.

			3 Developers = 3 routes.

			4 Developers = 6 routes.

			5 Developers = 10 routes.


		The group dynamics research finds that a group of 4 persons is the maximum recommended size if retained knowledge is key in the activities required to execute the task at hand. This is based upon the short-term memory capacity for typical people, which is about six to eight items at one time. Once you reach 5 people, then the short term memory limitations are reached, and one may start to lose track of the work at hand, what the last act was performed, who has ownership of a certain data item, etc.

		When one has to deploy a large project, a bus methodology is a common approach used to some success. In this situation there is a project manager or group of managers that behave like a bus arbitrator/controller. The persons working on individual tasks have access to resources, such as data schemas, functional specifications, previous work and possibly retained project knowledge. However, the information must be accessed indirectly through others. This adds an additional process to accomplishing a task, which will consume time and resources. Group information will be typically broadcast through electronic means, or possibly through group meetings in person. This method allows for a controlled approach of resource allocation, which can be in contention when large projects are being implemented.

		So one can see that group size and interactions between people working on IT tasks will have an effect on the outcome of a process. The analysis did not take into account additional interpersonal factors that would add a set of constraints that is not uniformly present for every project, or even process. Without any firm theory behind these interactions, we can only point out that the more people involved, the greater the opportunity to add sets of constraints that were not attended to by the business.



Methodologies Compared		The reader will notice that the above IT process design methodologies were listed not just in chronological order, but also in a sort of hierarchical fashion. Obviously there was no planning and there was an absence of a defined methodology when the first automated systems were constructed. The priority then was to prove that systems could be automated in the first place. Once the ability to construct automated systems was learned and experience gained in their construction, then the efficiency of automating the systems could be considered.

		With the novelty of automation worn off, attention could be restored to the goal of maximizing benefit using the given resources in a business process. So this would now include the design and construction of the automated system, where it must be planned just like any other business process design activity. That is the major differentiator between an undisciplined design methodology and all of the subsequent methods. Note that undisciplined methodologies are still used to this day and are appropriate for certain circumstances.

		The waterfall approach was the first planned methodology and focused on the design of the automation and system. The CASE methodology took the waterfall approach one step further and added the construction of the automated system as part of the design process. The CMM methodologies applied to both the waterfall and CASE methodologies, and added a consistent structure and metrics to their processes. Finally, the RAD and agile methodologies attempted to speed up the design processes and minimize the communications difficulties by added iterations to the process. RAD focused on large parts of the systems and ran through it multiple times. Agile broke the functionality of the systems into small portions, and built up the system by accumulating up the iterations of the small mini-systems.


		So how do these IT process methodologies compare to each other and to the business design process methodologies? This section is currently incomplete and being composed.

Similarities and Differences		Currently being composed.




Conclusion		Currently being composed.




		Return to Publications page	Navigate to home page

Legal

Last updated:
25-June-2005 01:29z