Iron Speed Designer in the Software Conversion Process

One wishes software foundations could be created that always serve an organization without the need for future conversions. However, both the needs of business and the power of information technology grow at rapid paces. The limitations of legacy solutions often can’t be refactored in ways that allow the company to benefit from newer solutions, or at least not without costing more than replacement.

Iron Speed Designer’s current direction is an effort to address this predicament. Iron Speed Designer allows the development team to create and manage solutions through configuration development and management. This concept works hand-in-hand with the Microsoft "Windows Presentation Foundation" (WPF) and "Model Driven Development" (MDD) initiatives. It also allows modeling requirements based on both human and system workflows, and has the ability to refactor those workflows in software configuration through higher levels of abstraction.

When one considers the shear number of configuration options within the current version of Iron Speed Designer, one reaches a true appreciation for what is available, especially when many applications can be generated over a well-designed DBMS without writing a single line of code. These levels of abstraction increase with each new Iron Speed Designer release, and promise to make the application an even more productive development tool.

Just one of the many configuration panels available in Iron Speed Designer 5.2.1.

Even as the ideal evolves and an organization’s need for change can be facilitated by underlying information system solutions, the inherent requirement to employ efficient software development lifecycle (SDLC) processes still exists. This is necessary to adequately capture the requirements and compare them to the existing architecture and then arrive at a more accurate future version of the desired solution.

Conceptually, the process is relatively simple, as illustrated in the following graphic. However, as in most complex processes, the devil is in the details. The process and subject matter are widely researched and documented, though too often the advice goes unheeded, giving rise to potential risks.

(COTS - Commercial Off-The-Shelf Software)

Analyze As-Is Processes: The objective of this step is to identify and document the current business processes, activities, decisions made during the process, and the required documentation (Inputs, Behaviors, and Outputs). This provides the foundation and documentation of the current application processes ("As-Is") to compare to the COTS functionality and desired "Best Practices." The goal is to identify the functional "Gaps" in the "To-Be" architecture that need to be addressed prior to application deployment. This process is most simply accomplished by having each business "Role" step through each of its job functions, take screenshots, record the behaviors/decisions necessary for completing that function, and then pair those with the outputs (screen views, printed reports, output files). These are then documented as Use Case statements in combination with the sample screenshots and outputs.

Develop To-Be Processes: This is created using the existing "As-Is" functionality, along with desired future functionality, best practices, and native functionality within the COTS product. In other words, this is the desired end-product solution Ideally, it will mirror the actual implementation in functionality.

Identify Functional Gaps: This is a comparison of the two above processes ("To-Be" processes minus "As-Is" processes) to arrive at the functional "Gaps" between the two. One then defines the functional processes that need to be addressed.

Prioritize Gaps: Once the Gaps have been defined, each Gap is then prioritized into a hierarchy that makes sense for the organization and project at hand. Once prioritized, one of three methods will be considered for addressing the deficiencies...

• Configuration – resolve the Gap through a native configuration available within the COTS product, either through configuration alternatives or through the product SDK.
• Workaround – arrive at an acceptable workaround within the native COTS product that solves the functional requirement.
• Customization – modify the COTS product to address the functional requirement, either directly or indirectly. This is typically the most expensive means of addressing a functional requirement. If it is created in a manner that involves a dependency upon the native COTS product, it typically results in a recurring expense because the customization must be addressed with each new COTS product upgrade.

Project management proverb: "What is not documented has not been said."

The Robbins-Gioia Survey (2001)
The Conference Board Survey (2001)
The OASIG Study (1995)
The KPMG Canada Survey (1997)
The Chaos Report (1995)

The single greatest reason identified for ERP implementation failure at one or more levels is inadequate definition of functional requirements in both the "AS-IS" and "TO-BE" documentation . This demonstrates the importance of taking the necessary additional time to achieve accurate and complete definitions at this juncture.

Iron Speed Designer can facilitate an organization’s development requirements in a number of ways:

1. As the COTS product, which must be configured to model the organization’s requirements using the "As-Is" documention. This is the litmus for ensuring all of the organization’s functional requirements are met.

2. As either an ad-hoc or permanent Software Projects Requirements solution for gathering and documenting both the "As-Is" and "To-Be" processes. (A sample SPR program writtin in Iron Speed Designer will be made available as an open architecture solution/project in the Iron Speed user forum).

3. As the Service Oriented Architecture (SOA) user interface created to manage and facilitate information-interface requirements between Line of Business (LOB) applications within an organization. (A future article on this subject is in the works.)

Les Cardwell, is an Enterprise Architect/Senior Programmer Analyst for Central Lincoln Peoples Utility District in Newport Oregon, and the President of White Box, Inc. which specializes in the design, development, and distribution of vertical application solutions built using Iron Speed Designer. Prior to establishing this company, Les spent nine years in project management and consulting as the Vice President of PLM Consulting, Inc.

Les holds a Masters of Information Technology, and graduated summa cum laude from American Intercontinental University.