Development Approach

Rational application development should be the goal of any Information Technology operation. Unfortunately, a methodical, rational approach goes out the window (whichever version) when ideas collide. Developers, technically oriented, tend to offer up suggestions on strategic development paths heavily weighted with bias. And not always based on their actual experience.

Recommendations of application development strategy from developers generally fall into one of two categories. 1) Go-with-what-you-know: A developer has spent years developing an expertise in a specific discipline on a specific architecture, (IBM or Sun or, a Microsoft platform). It is common for a technician to make a recommendation for a strategic direction that favors a solution based on familiarity. a. Windows developers tend to recommend a Microsoft solution b. IBM mid-range developers tend to recommend a strategy based on IBM. 2) Set-a-new-Course: A developer has spent years developing expertise in a specific discipline and wants to move on to something new—adding to the tool box while increasing the potential for the individual’s marketability and earning power. a. The recommendation could be a result of the latest technology trend b. The recommendation could be the result of the latest job trend

In truth, there is nothing wrong with a strategic direction based on either type of recommendation—both have merit, both have risk. There is no crystal ball to determine if a technology trend is something that blossoms into a generally accepted industry standard, or if it is one of the many evolutionary dead-ends that litter the brief history of IT, (nobody remembers PL/1). Yet at the same time, staying with a known commodity entails risk as well. At the pace of technological advancement, even current technology is a risk of being obsolete in 18 months. (see: Moore’s Law; Gordon Moore, Fairchild Semi-conductor).

iSoftwerks Design

Modular Design Philosopy

The program design concepts used by iSoftwerks, Inc. are not necessarily unique in theory, but rare in implementation. Though written primarily in RPG, the development model varies greatly from the early models of top-down procedural codes familiar to most long-time RPG developers. It is far more similar to the modular, event driven concepts that are found in the stateless environment of CGI development, or web processes.

Modular Design

In the SoftCode environment, programs are generally constructed without containing a database file. Instead the program is bound to a service program or file manager module which contains the data to be acted on. Typically an interactive program only manages the presentation of the data and the data management itself is left to the I/O manager.

This separation of presentation from data (and business rules) allows the RPG application to be relatively small. Keeping the code compact makes maintenance easier and faster. And since time is money, it also is cheaper to maintain throughout the Software Development Life Cycle (SDLC). There is also a valuable by-product of this very modular style development; re-usable functions. Since the data management is separate from the data presentation, web applications and traditional 5250-style applications can share the same data and data services. (WDSC, (Websphere Development Studio Client, will allow service programs to be exposed as web services.)

Application Model

With the introduction of the Integrated Language Environment (ILE) IBM offered a model of how to build models aimed at providing services from a common interface. The current IBM Power Systems platform increases the opportunity to move forward toward SOA with current tools and application development languages—embracing the soft-coded application model, where functions are external to the program, rather than traditional top-down monolithic structures can help create re-useable functions that are easily maintained and easy to learn.

The iSoftwerks approach to development model takes advantage of the ILE structure to create service programs very much like Java classes. A Java class may be composed of a number of methods, bound together. If a class is imported to an application, the methods of the class are directly available to the application. The major difference is service programs may be constructed of modules of many different languages, RPG, C++, COBOL, CL, etc. The components of the service program are referred to as procedures instead of methods, but like a class, once a program is bound to the service program, the application will have access to the procedures contained in the service program.

What about SOA?

There is no real need to replicate rules or I/O functions in order to serve up information. It has the added benefit of applying the same rules to data from the web side, or the 5250 side of the equation. Since the information is presented from a common source, the information displayed on a 5250 screen will match exactly the information presented through the browser—since the data source is the same. The User Interface (UI) is applications are separate from the services, but bound to the same service program procedures, so they are sharing common functions. This type of application structure produces reusable code and fits into the idea of creating SOA type applications.

At the highest conceptual level, applications should simply provide services. The popular SOA (Service Oriented Architecture) concept describes the goal fairly well. Because ultimately, isn’t that what a business, any business, is about—providing services to a customer? Of course, without further definition, SOA is just another TLA (Three Letter Acronym).

The W3C defines SOA as: “A set of components which can be invoked, and whose interface descriptions can be published and discovered.”

Quite frankly, with apologies to the W3C, that definition falls short of the mark. In the first place, components don’t always appear as part of a set. Secondly, by W3C definition, SOA is only comprised of implemented and deployed components, rather than the model on which they were built, (the ARCHITECTURE, if you please).

Architecture implies a style, deployed or not. A more practical definition of SOA might be: The standards, practices, and models, that enable application functionality to be provided and consumed as services published to satisfy the requirements of the service consumer. Services may be invoked, published and discovered, regardless of implementation through a single interface, based on a common (standard) form.

Development Issues

Often overlooked in the technical consideration of application development is the nature of computer systems. All computer systems, past, present, and future, consist of five common components; hardware, software, input, output, and people. The real pit-fall of both directions above is the failure to address non-technical issues. 1) What machine resources are available—what hardware is currently in place a. Are the resources leased, or owned b. What is the cost of new hardware, versus paying maintenance fees on existing hardware c. Does the direction require additional hardware at the client level d. Are vendors in place (and willing) to support a change e. What is the ROI of migrating to a new platform (change for the sake of change cannot be cost justified) 2) What development resources are available a. Does the strategic direction leverage existing software b. Does the new development effort require additional client licenses c. Are technical resources available to support the strategic direction; i. In-house ii. Contractors iii. Software development firm d. Are those technical resources within budget e. What is the cost of re-training employees 3) What is the impact a new direction will have on the flow of information into the system a. How will new development impact internal data flow b. Will new operational processes be required c. Can business partners accommodate changes to a data exchange 4) How will new development manage data presentation a. If the presentation changes, what is the cost to retrain employees b. Will the new presentation require new security measures i. Is it available to download c. Will data exchange change i. Between business and consumer ii. Between business and supply chain iii. Between business and partners 5) Are the right people in place to manage and execute the strategic direction a. At the technical level b. At the project management level c. At the operational level d. At the training level e. At the user level

A rational approach to a strategic application development plan has to address these details and answer three fundamental questions. First and foremost; where are we? An honest assessment of current systems should be performed. Where do you want to go? What are the goals and objectives you want to meet over the next (insert number) years. How much of the current system can be leveraged to preserve the company’s original investment within the frame work of the application development plan?