Business Technology

My name is Mark Murphy.  I have been working in the IT industry since 1989, and have been with Star Base Inc. providing IT Solutions in Cincinnati for over a dozen years.  My primary emphasis has been with IBM midrange systems doing work as an administrator, programmer/analyst, business analyst, and trainer.  My philosophy is that IT should be transparent to the everyday work of a business.  Ninja like, unseen but highly effective.  The IT department should be responsive to its customers (the users of its services).  A thorough understanding of their needs is key to providing a workable approach to IT processes automation.

To be most effective it is important to remain up to date on the latest technologies and trends.  In this blog I intend to discuss things I am learning, and technologies and techniques I have discovered that make it easier to deliver on the goal of IT supporting business rather than business supporting IT.  Help me to understand your needs, and I will blog about that too.

Sometimes the solution to a problem is staring you right in the face.  Sometimes you already know the answer but can't see it because the pieces are labeled in a way that is outside the scope of the solution.  Sometimes you can just use an old tool to provide a piece of functionality you thought you needed to code a home grown solution for.  Recently, such a time occurred for me.

I was in a meeting discussing the logistics of transferring multiple gigs of text data across the internet.  The source computer was an iSeries, the target was something else.  Much of the discussion centered on network latency and the time it was going to take to transfer that much data, and how processes were going to have to be pushed back a day because the window was too short.  Well I said why don't we just zip up the file and send it that way.  Data files tend to be highly compressible, up to 90%.  "Can you do that on an iSeries."  That was the infrastructure guy.  Why not, I can run Java on it.  I shouldn't be too hard to find something, even if I have to write a simple Java program.  "Don't do anything we won't be able to understand."  That was one of the RPG programmers.  IMHO, the legacy tag belongs with those who use the technology, and the technologies  they choose to use rather than with the hardware and operating system.  For me it was a challenge.

A day later I had a working command using a tool that is bundled with every Java Development Kit.  I knew this, but it took a slight memory jog from a college to remind me.  A JAR file is a ZIP file with a different extension.  IBM explicitly provides a tool to convert a database file to a CSV file, or a flat text file, but to compress that file into a ZIP file you need to use the JAR utility and give the file a .ZIP extension.  Works like a champ.  IBM even provides an alternate JAR utility that acts more like a command line compression utility to create zip files, but instead of calling it zip, or izip or something like that they call it ajar.

Well, a short CL later and I have a full featured program that takes a database file name, a zip file name and path (in the integrated file system or IFS), and a format selector (*DLM or *FIXED).  It probably would have made more sense to name that format *CSV instead of *DLM, but IBM's conversion utility calls it *DLM.  The output is a zip file with the name and path as specified in the input parameters.

And Here it is:

             PGM        PARM(&DBF &ZIPFILE &FORMAT)


             DCL        VAR(&DBF) TYPE(*CHAR) LEN(32)
             DCL        VAR(&ZIPFILE) TYPE(*CHAR) LEN(255)
             DCL        VAR(&FORMAT) TYPE(*CHAR) LEN(6)
             DCL        VAR(&FILE) TYPE(*CHAR) LEN(10)
             DCL        VAR(&LIB) TYPE(*CHAR) LEN(10)
             DCL        VAR(&MBR) TYPE(*CHAR) LEN(10)
             DCL        VAR(&CMD) TYPE(*CHAR) LEN(255)
             DCL        VAR(&TEXTFILE) TYPE(*CHAR) LEN(15)
             DCL        VAR(&TEMPFILE) TYPE(*CHAR) LEN(40)
             DCL        VAR(&ERRLOOP) TYPE(*CHAR) LEN(1) VALUE(N)
             DCL        VAR(&INTER) TYPE(*CHAR) LEN(1)

             MONMSG     MSGID(CPF0000 QSH0000) EXEC(GOTO CMDLBL(ERROR))

             RTVJOBA    TYPE(&INTER)

             CHGVAR     VAR(&FILE) VALUE(%SST(&DBF 3 10))
             CHGVAR     VAR(&LIB) VALUE(%SST(&DBF 13 10))
             CHGVAR     VAR(&MBR) VALUE(%SST(&DBF 23 10))

             /* Ensure ZIP directory exists for error logging */
             MKDIR      DIR('/zip')
             MONMSG     MSGID(CPFA0A0)

             /* Delete &zipfile if it exists */
             RMVLNK     OBJLNK(&ZIPFILE)
             MONMSG     MSGID(CPFA0A9)

             /* build text file name */
             IF         COND(&FORMAT *EQ *DLM) THEN(DO)
                CHGVAR     VAR(&TEXTFILE) VALUE(&FILE *TCAT '.csv')
             ENDDO
             ELSE       CMD(DO)
                CHGVAR     VAR(&TEXTFILE) VALUE(&FILE *TCAT '.txt')
             ENDDO

             /* generate temporary file name */
             RTVTMPIFSN NAME(&TEMPFILE)
             IF         COND(&TEMPFILE *EQ ' ') THEN(CHGVAR VAR(&TEMPFILE) +
                          VALUE('/tmp/$$__tempfile'))

             /* export DBF to temporary file */
             CPYTOIMPF  FROMFILE(&LIB/&FILE &MBR) TOSTMF(&TEMPFILE) +
                          MBROPT(*REPLACE) STMFCODPAG(*STDASCII) +
                          RCDDLM(*CRLF) DTAFMT(&FORMAT) RMVBLANK(*TRAILING)
             MONMSG     MSGID(CPF2817) EXEC(DO)
                SNDPGMMSG  MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA('Error +
                             converting Database File to Interface File') +
                             MSGTYPE(*DIAG)
                GOTO       CMDLBL(ERROR)
             ENDDO

             /* Send 'compressing' status message */
             IF         COND(&INTER *EQ '1') THEN(SNDPGMMSG MSGID(CPF9897) +
                          MSGF(QCPFMSG) MSGDTA('Compressing file ' *CAT +
                          &FILE) TOPGMQ(*EXT) MSGTYPE(*STATUS))

             /*---------------------------------------------------------------*/
             /* This command is using the unix environment to zip up the file */
             /* extracted above.  All errors are logged to a text file        */
             /* named error.txt.  The 2>> operator redirects stderr to the    */
             /* file following it, and adds any messages to the end of the    */
             /* file.                                                         */
             /*                                                               */
             /* The following unix utilities are used here:                   */
             /*  ajar - create an archive                                     */
             /*                                                               */
             /* The following environment variables are used here:            */
             /*  QIBM_QSH_CMD_ESCAPE_MSG - Sends QSH0005 as an escape message */
             /*        if the exit status is not 0 (Qshell error condition)   */
             /*---------------------------------------------------------------*/
             /* Send an escape message if the command fails */
             ADDENVVAR  ENVVAR(QIBM_QSH_CMD_ESCAPE_MSG) VALUE(Y) +
                          REPLACE(*YES)

             /* Create &zipfile from temporary file */
             CHGVAR     VAR(&CMD) VALUE('ajar -c -M' *BCAT &ZIPFILE *BCAT +
                          '''' *CAT &TEMPFILE *TCAT ''' :' *BCAT &TEXTFILE +
                          *BCAT '2>>' *BCAT '/zip/error.txt')
             QSH        CMD(&CMD)
             MONMSG     MSGID(QSH0005) EXEC(DO)
                SNDPGMMSG  MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA('Error +
                             creating ZIP file') MSGTYPE(*DIAG)
                GOTO       CMDLBL(ERROR)
             ENDDO

             /* Delete temporaty file */
             RMVLNK     OBJLNK(&TEMPFILE)
             MONMSG     MSGID(CPFA0A9)

             /* Exit Normally */
             GOTO       CMDLBL(OUT)


             /* Process Errors */
 ERROR:      IF         COND(&ERRLOOP *EQ Y) THEN(GOTO CMDLBL(OUT))
             CHGVAR     VAR(&ERRLOOP) VALUE(Y)

             /* Delete temporaty file */
             RMVLNK     OBJLNK(&TEMPFILE)
             MONMSG     MSGID(CPFA0A9)

             /* Send Escape message */
             SNDPGMMSG  MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA('Error +
                          Processing File') MSGTYPE(*ESCAPE)

 OUT:        ENDPGM

Check it out.  Create a ZIP file using the Java Archive utility.  A Rose by any other name would smell as sweet!

Ok, I have two things to talk about today, neither of which can be modeled directly in an E-R diagram or in UML.  As an application development team member, I tend to see patterns.  For example, a manager is a kind of employee that has subordinates, or vendors and customers are very similar, and have pretty much the same roles, except we buy things from vendors, and sell things to customers.  Wouldn't it be nice to say in your model that a manager is a type of employee, or that both vendors and customers are individuals in my address book.

In this example an Employee is identified by an id, and has a Name.  In addition, a Manager is a type of Employee that has a budget.  Manager is the subtype.

In addition to having a budget, another thing that differentiates a manager from other employees is that the manager has subordinates.  We can model that by saying that Manager supervises Employee. 

There is one last thing to do here.  We want to make sure that a Manager is not his own supervisor.  If we did not put any constraints in place, then any employee could supervise any other employee, including himself, or his supervisor.  To do this comprehensively we would want to make sure the structure did not eventually end up in a ring where A supervises B who supervises C who supervises A.  The constraints that restrict how these structures can be built are called ring constraints, and there are several types with very mathematical names.  Unfortunately each tool represents these ring constraints differently so you need to know the names.  In ORM there are six of them, and they have names that conjure up notions of higher mathematics: 

1. Irreflexive  - means that the two roles cannot be filled by the same instance of an object.  Our Manager supervises Employee fact type is irreflexive meaning a particular manager cannot be his own supervisor. 
2. Symmetric - means that if a relationship exists between two instances of an object, then the same relationship exists in the opposite direction.  If Ohio borders Indiana, then Indiana borders Ohio.  Our Manager supervises Employee fact type is not symmetric.
3. Asymmetric - is mostly the opposite of symmetric.  If a relationship between two instances of an object, then the same relationship does not exist in the opposite direction.  Our Manager supervises Employee fact type is asymmetric.  Note that asymmetry implies irreflexivity.
4. Antisymmetric - is kind of like symmetric with asymmetry in specific instances.  So in the antisymmetric relationship, if the same instance of an object is playing both roles of a fact, then it is symmetric, but if different instances of the object are playing the roles of a fact, then it is asymmetric.  Here is an example of an antisymmetric fact type: Number is greater than or equal to Number.  It is symmetric as long as the numbers are the same, otherwise it is asymmetric.
5. Intransitive - Intransitive has to do with chaining relationships together.  If Object A relates to object B, and Object B relates to Object C, then intransitivity say that Object A may not have that same relation with Object C.  Consider parents and children.  Joe is the father of Mark who is the father of Tom, then Joe can't be the father of Tom unless there are some illegal behavior going on.  That is intransitive.  In most organizations, the Manager -> Employee relationship is intransitive.  Note Intransitivity implies Irreflexivity.
6. Acyclic - Means that for any object, I can't follow the chain far enough to get back to the starting object.  A parent can not be it's own descendant.  This constraint is very expensive to impliment in terms of processing resources, so it is typically not specified.  Usually Acyclic relationships are specified as Asymmetric.  Note Acyclic implies Asymetric which implies Irreflexive.

If your brain now hurts as much as mine did when I was first trying to figgure out these ring constraints, you might find Verbalizing Business Rules: Part 12 by Terry Halpin useful.  Much of this post was inspired by this document.  However, be prepared to spend a lot of time in deep thought, and possibly additional research.  As I said, different tools depict ring constraints differently, so here is what the Manager supervises Employee looks like in Norma (a Visual Studio ORM plugin).

www.orm.net/

and a book by Terry Halpin and others:
Database Modeling with Microsoft Visio for Enterprise Architects

Previously I talked about some ORM basics, and internal constraints.  With just these parts one can build a fairly sophisticated information model.  But there are times that one fact type will depend on another in some way.  For example say I want to model a telephone survey of some type.  A caller will make phone calls and ask the person on the other end some questions.  The answers to these questions will be recorded either as a multiple-choice selection, or as a free-form "essay" type answer.  For a given question, an answer must be recorded in exactly one of these two forms.  We have a couple things going on here, so I am going to break it up into logical parts.

First an Answer is given for a Question during a Call.  This is not the typical binary fact type that we have been dealing with so far, but in ORM we can still record these fact types and give them internal constraints.  Going to the diagram we have the following:

There are no external constraints here, but you can get a decent idea of just what can be modeled with more advanced fact types.  Note the mandatory constraint requiring a question and a call for each answer given, and the uniqueness constraint saying that a question asked during a specific call identifies a particular answer.

Here is another way to model the same information using binary fact types and an external unique constraint:

In this case an external uniqueness constraint is applied to the Call and Question roles of the Answer applies to Call and Answer given for Question fact types.  There is a difference between these two models though.  Can you detect it?  In the first model, the same answer can be given for more than one question as long as it is given on a different call.  Functionally this means that in the second model, each answer given is it's own answer with it's own answer id.  I modeled this in Visio for Enterprise Architects.  And though I would like to put a uniqueness constraint on the Answer role in the first model, Visio does not allow that.  I have not tried this with other tools.

What about that part where I want to require either a multiple-choice answer or a text answer?  I have another external constraint for you.  Here is the diagram.


This is a mandatory constraint on the answer role relating the two fact types.  This means that an Answer bust have a choice, or some text.  Still it could have both, so I need another constraint.  One that means that I can't have more than one of each of the related roles in play.  I have not talked about this constraint type yet because it really doesn't apply to internal constraints.  It is called an exclusion constraint, and this is what it looks like on the diagram.


Note that both the mandatory and the exclusion constraints are attached to the answer role while the uniqueness constraint is on the other role.  Note that for a given answer, the answer cannot be unique across the two fact types, it has to be the same on the same fact.  The uniqueness constraint applies to the roles it is attached to.  Mandatory and exclusion constraints apply to the other role.  For a given Answer (role the constraint is attached to, at most one of the fact types is allowed.  If we combine the mandatory and exclusion fact types we get an exclusive or construct that would mean for each Answer, exactly one of the two related fact types are required.  See the diagram:


It is hard to see, but if you look closely you will see the X in the circle behind the dot.  Note also, that these constraints can be extended beyond two fact types to mean exactly 1 of n or at least 1 of n or no more than 1 of n.

Next time I will talk about ring constraints and something that no case tool based on ER models (that I have used) can do.

Last time I discussed the basics of an Object-Role Model.  The model we created, however, was simplistic, and didn't give us a way to say that a Person must have exactly one name, or that a person might have more than one phone number.  These things are handled by constraints placed on the roles.  The application development team has a fairly extensive set of constraints at it's disposal when creating an ORM.  I will talk about the most common of these this time.

Internal Constraints are those that apply completely to roles within a single fact type.  Let's go back to the Person model we developed last time (slightly modified).


We can attach an internal mandatory constraint to the Person role in the Person has Name fact.  This is somewhat counter-intuitive, but constraints apply to the other role in the fact.  I attach the mandatory constraint to the Person role in the Person has Name fact.  That means that each person must have some name.  If I attached the mandatory constraint to the name role, it would mean that for each name, some person must have that name.  Another way to say it is that a constraint goes on the controlling or primary role.

This is what this constraint will look line on the diagram:



We can also attach uniqueness constraints to roles.  As with the mandatory constraint, the uniqueness constraint applies to the other role.  So to say that a Person may have at most one Name, we will attach a uniqueness constraint to the Person role of the Person has name fact.

The uniqueness constraint will look like this on the diagram:



When combined, these two constraints mean that a person has exactly one name:



What about that phone number?  I have multiple phone numbers, my home phone, my cell phone, and a couple of work phones.  In addition, my home phone and my work phone numbers could be claimed by other people as well, and some people may not even have a phone number, or it is unlisted and we don't know it.  In this case, the Person has Phone Number fact type has no mandatory constraints, and it takes both the person and the phone number to make a unique fact.  As an aside here, up until now, I have been using fact type and fact rather interchangeably, but that is not strictly correct.  The fact type is an abstraction of the real facts, thus Person has Phone Number is a fact type, and Mark has Phone Number 123-4567 is a fact.  The point here is it takes both the person Mark and the Phone Number 123-4567 to make a unique fact, so to add the uniqueness constraint we would add it against both roles simultaneously. 

This, for the application development team, is a many-to-many relationship, and looks like this on the diagram:



I will show one final combination today.  For the sake of example, suppose that I could only have a single e-mail address, and every e-mail address could only be used by a single person, not reality I know, but what you would have is a one-to-one relationship.  In that case you could say it like this: Each person has at most one e-mail address, and each e-mail address is used by at most one person.  There are two internal uniqueness constraints here one for the person role, and one for the e-mail address role of the Person has E-mail Address fact type.

These constraints would look like this on the diagram:



As you can see, with just binary fact types and a couple internal constraint types (mandatory and uniqueness), the application development team can model nearly everything that can be modeled on an ER diagram.  And you have natural language descriptions of the model that are readable by the business users the solution is being developed for.  But wait there's more.  I will tell you about external constraints, and reference modes next time.

The object role model is a simpler approach to creating the information model that the application development team will use to create the physical database for IT solutions.  It centers around a single structure called the fact type.  Here are a few fact types for a simple address book application.


This is nice, and easily understood, but I like diagrams, and that is simple too. The tools I have seen allow typing fact types in a natural language manner, or by adding them graphically to a diagram like this.



Note that there are three different symbols: the oval with a solid line which represents an entity, the oval with a dashed line which represents a value, and a rectangle with two boxes which represents a fact (sometimes called a predicate).  It is up to you to determine if an object is a value or an entity.  There are a couple of ways to do this.  One is if you can write it down, then it is a value, otherwise it is an entity.  For example, you can write a person's name on paper, but can not write the person.  Another way to determine this is if it has components, then it is an entity, otherwise it is a value.  An address could be written down, but sometimes we want o refer to a component of the address, so we make that an entity, and the individual components of the address become values like this:


Or graphically



You get the idea.  As an exercise you might want to try extending the model to allow states in different countries.

That's it.  An Object-Role Model is built using simple facts.  In this case, and most cases, the application development team can use binary facts (ones that reference or or two objects playing two roles).  The tools I have seen allow n-ary fact types as well, but the uses for these are uncommon, and in my experience can be replaced by binary fact types.  In my next post I will discuss uniqueness and mandatory fact types

Recently I have been working on a project revamping a very poorly designed database.  This activity brought me to look for some new tools, and I came across something called ORM.  That is Object-Role Modeling, not to be confused by my developer friends in the OO world with ORM or Object Relational Mapping.  Somewhere, somehow, we have to get a handle on all these TLAs, but I digress.  In the past I have touched briefly on the apparent divide between the business and IT.  If both of those groups would just speak the same language then application development be better for it, and IT would be able to support the business in the way it was intended.

So what does Object-Role Modeling do for me?

ORM is not a new concept - it dates back to the 1970's, but it is a way to build simple information models using nothing more than simple facts.  For example a Customer has a Name.  When designing a new system, or even upgrading an existing system, we can easily retrieve these natural language facts, and combine them into a powerful information model that the business can look at and say "yes that is true, but you forgot that a customer also has an address!"  Add a couple constraints that tell about the relationship between the object and it's roles, and the developers can automatically generate all the ER diagrams and class models it wants.  ORM provides a simpler, more accurate and more powerful approach to information modeling than other approaches such as Entity-Relational Modeling and UML.

ORM is really a very simple approach that, once you get past the "there has to be more to it" reaction, will give you some better communication tools for use between the business and the application development team.  In fact if they don't already know it, ORM has been part of Visio for Enterprise Architects for quite some time now, and there are even some open source ORM tools that plug into Visual Studio.  The integration of these tools into your application development environment will make your business analysts and database analysts far more productive.  As such I will impart, over the next couple of posts, some tidbits that will get you going.  In the mean time if you are chomping at the bit, I suggest you jump over to The ORM Foundation for some additional reading.

Tools are supposed to make tasks easier.  A hammer makes it easier to drive nails, application development tools make it easier to deliver complex applications efficiently.  Too often though, applications, tools for users, do not make the users' lives easier.  Consider an on-line banking application provided by a major home improvement company (you might think they would get the concept of tools).  I want such an application to make it easy to manage my 12 month same-as-cash transaction so that I can have say $50.00 automatically transferred from my checking account and applied to the purchase on the first day of each month until it is paid off.  And to make it totally convenient it should recommend a payment amount and payment date so that I have the lowest possible payment while still paying off the purchase on time.  I can dream can't I?

That isn't even close to reality.  Instead, if I had regular purchases, or more than one 12 month same-as-cash purchase, I would have to go on-line, and make a payment.  Then after the payment posted, I would have to remember to go on-line again and, through their special messaging system, send customer service a message telling them how to apportion the payment that just posted.  No thanks, it is easier just to mail a check, and make sure I don't have more than one large purchase from them in any given 12 month period.

The result of application development is tools that must support the business and the user.  These tools must allow the business and the user to work more efficiently without extra steps artificially inserted into the process.  Too often application development teams have a corporate mindset.  That is, if you have a way to complete your task, that is good enough.  There is no competition, and the user doesn't have a choice.  When that attitude becomes a way of life, they forget that consumer's do have a choice, and will happily look elsewhere if the tools make their lives easier.

Frameworks have become the rage in OO application development, and despite the inherent need for programmers to build it themselves, using a well designed and well supported framework can save you significant time when developing applications for the web.  Let's face it, web applications have a whole set of constraints and threats that local applications don't have, not the least of which is security.  An IT Strategy Consultant can help you choose a framework that will boost your productivity and make your applications more secure.

A good framework relies on well researched design patterns like Model-View-Controller (MVC) to make it easier to apply coding techniques like Don't Repeat Yourself (DRY).  While this can appear to make applications more complex, in practice a modular application based on an MVC framework will help maintain consistency of the application.  If there is only one piece of code that calculates item prices, then wherever those prices are needed, they will always be calculated the same way.  This may seem totally intuitive, but you would be surprised the number of applications I have seen where the same task is coded separately in each place it is needed.  In fact that is how the monolithic programming style worked.  Each program contained all of its code, and it was, usually, easy to see where that program needed to be changed to fix the pricing rule.  Unfortunately, it was much harder to find all the programs that the pricing rule needed to be changed in.

A good framework will contain an abstraction layer to shield you from the nuances of your specific database.  When the time comes to change database engines you won't be stuck with a major rewrite.  Yea, I know you have used the XXX database forever, and will never change.  And in Cincinnati, pigs can fly!  Acquisitions, mergers, changing business requirements, and other things can cause your simple IT Infrastructure to become complicated beyond your ability to effectively manage it.  Consolidation frequently involves choosing a database and porting everything else over to it.

A good framework has a thriving developer community behind it.  This makes it easier to retain application developers, get training, and get questions answered.  This also means that security threats are quickly addressed to keep your data safe in the brave world of the internet.

As a good IT strategy, choosing and using the right framework can boost the productivity of you application development staff, and make your applications more consistent and more secure.

It’s the end of an era.  I have been at the same client now for over a dozen years, but the economy and a large ERP project have taken their toll.  Now there is no money to keep me on board.  It’s been a good run, and I have seen a lot of stuff, but I can’t say I am not looking forward to seeing something new.  Twelve years is a long time to be in the same place.  When I first started IT consulting in Cincinnati, OH, I had six or seven different clients in the first two years; sometimes two at a time.  It never ceases to amaze me the number of ways there are to approach a given problem, and I never tire of learning new things.

As I reflect on the last decade, I realize that I love working with the iSeries and i5/OS.  You might say I have become somewhat of a bigot for that platform.  I don’t know of any other platform that is as stable and reliable as the iSeries.  It is easy to learn, easy to use, you plug it in and it works.  Hardware and OS upgrades do not create a need for rebuilding or redesigning applications.  The same box can safely serve multiple loads, and the OS is actually able to (and does) keep jobs from stepping on each other.  Despite being on the cutting edge of technology, IBM i as it is now known has the ‘legacy’ tag.

As a result, IBM has merged the System i hardware with the System p, and launched Power Systems.  The OS is your choice: AIX, IBM i, or Linux.  That lets them continue to support i without having to build separate hardware for that ‘legacy’ platform.  Oh, and by the way, when IBM reports sales numbers, the old System i hardware is still reported by itself, and being older technology, those sales numbers are in a freefall.  System p numbers however, are reported combined with Power Systems, and include the numbers for all Power Systems whether they are being sold with IBM i, AIX, or Linux.  To be honest, it isn’t the hardware that matters, but the operating system that gives a computer its character, but the reporting of the new Power Systems gives a false impression that customers are leaving IBM i in droves.  Perception is reality, and IBM, intentionally or not, is killing off the i.

It isn’t just IBM though.  There aren’t many programmers coming out of college that want to program using RPG.  And everyone knows that IBM i can only use RPG against a DB2 database that really isn’t DB2. <sarcasm off>  It is rare that you find Java, PHP, or MySQL running on an i.  Even though Java has been available almost since it’s inception, and PHP has been available since i5/OS V5R3.  Two releases of the OS later, people still as me if IBM still upgrades the operating system or the hardware.  Yes but perception is reality.  I still love the box, and the OS.  It is as close to an appliance as anyone in the computer industry will ever get, while still being able to scale to mainframe proportions.

What is a poor RPG programmer to do?  Learn Java, learn PHP, bring your skills into the 21st century.  It is the end of an era, and you don’t want to be caught with the legacy tag.

It used to be that RPG programmers could easily find good jobs just because they knew RPG and the handful of other TLA's that go with it.  It is getting significantly harder!  Let's face it, there aren't very many students coming out of college wanting to program in RPG.  It is time to upgrade your skills, and there are plenty of directions to take.  Consider that the AS/400 (System i, iSeries, i5, i) runs both Java and PHP code, and can host a full fledged lamp stack (including the MySQL component).  I would recommend starting there.  In fact, IBM is putting its money into bringing PHP onto the platform by licensing Zend Core and Zend Studio for you when you buy i5/OS v5r3 and later.  Better yet, you can learn PHP (and Java for that matter) without having to go to the expense of purchasing an i5 Server.  And PHP does not require you to use OO programming techniques if you aren't used to that.  You can learn the PHP syntax, and then when you are familiar with the basic language constructs you can head down the OO path.

So roll up your sleeves and get started expanding your skill set.  Your career will thank you.

Now if you are a business owner, and are reading this, you may be thinking, "Hey, if there are less and less RPG programmers out there, and virtually no new ones being trained, why should I keep my iSeries?"  That is a topic for another post, but a better question would be - in light of the iSeries' capability to run i5/OS, AIX, and Linux natively, and Windows on an internal processor card - "Why should I scrap the system I know for one I don't know?"  Programming languages (except those coming from Microsoft) are becoming increasingly platform agnostic.  Write once run everywhere is no longer just a Java thing.  Consider that when making your next server decisions.

I’m pretty handy; in fact I am currently replacing the floors in the bedrooms of my house.  Why pay the labor to get something done that I can do myself?  It’s admittedly a funny attitude for a contractor to have, but I got it from my old man whose parents lived through the depression.  So I’m a bit of a tightwad, but I can understand when I talk to a business owner or IT manager who can’t envision using a contractor to get a job done because they can do it themselves.  Reminds me of the guy who said “a consultant’s someone who uses your own watch to tell you what time it is”.  As handy as I am: replaced my own roof, remodeled my bathroom, built my deck, etc.  There are some things I just won’t tackle.  Usually it is because I don’t have the tools, the skills, or the time.  This brings me back to consulting.  Why would you hire a consultant?  It all boils down to tools, skills and time. 

Do you want to try out some new technology and need a proof of concept?  Before dropping a bundle on a tool set that you may not ever use, hire someone to build a prototype, or concept system for you.  If things go as expected, the consultant can no only get you up and running, but train your staff to replicate the process, and recommend tools for moving forward. 

In addition to bringing new tool sets to the table, the right consultant will bring new skills as well.  A consultant can act as a mentor, a trainer, or an independent set of eyes to help you see things in a different light.  In fact, a consultant can be brought in to help with high level design work to show you some ways of doing things that you haven’t thought of.  It is easier for a consultant to think “outside the box” because he lives outside of the box you call your employer.

And then there is the ever present “too much to do, too little time” issue.  If you have a backlog of projects hanging over your head, but not enough people to get it all done, you need to hire someone, either permanently, or temporarily.  A consultant can help you knock out that backlog, and then go home when he is finished.  My old man who wouldn’t hire someone to do something he could do himself bought an apartment building.  The thing eventually got run down because he didn’t have the time to keep it maintained, and after a while everyone moved out.  It became a negative drain on his finances rather than a positive force.  Don’t let that backlog become a negative drain on your company.  Get it knocked out so that IT can properly support your business into the future.

If you read forums or mailing lists you have no doubt noticed some interesting tag lines at the ends of the posts.  One that I noticed the other day said "What is worse than training your staff and losing them?  Not training them and keeping them!"  Think about that for a minute.  Some professions require continuing education to keep up to date with the latest techniques and safety measures.  Consider a surgeon or even a paramedic that is still using 10 - 15 year old methods, but can't update because their employer thinks it is too costly.  How about a tax accountant who can't be bothered to keep up with current tax laws?  Education is critical to keeping your staff operating efficiently, and keeping them up to speed with current methodologies.  This allows your business to operate at peak efficiency, and helps prevent obsolescence.

Unfortunately, in the world of technology, where change sometimes happens at what appears to be the speed of light, many employers opt to minimize, or even prohibit training due to the cost.  In the midrange world, IBM has unwittingly made this strategy easier on businesses.  Even though IBM's midrange technology has kept pace with, and in many ways maintained a healthy lead over its competitors, the architecture of these systems, the AS/400 and it's successors in particular, has allowed the old techniques to perform equally with newer techniques.  In fact this protects the investments of the companies that have come to rely on these systems better than any other line of computing equipment.  But, in the absence of continuing education, many of these IT shops have found it hard to find new developers versed in the old ways.  They may even, mistakenly, believe that these systems can not effectively support newer object oriented programming models, web based applications, and open standards.

Cost isn't the only inhibitor to continuing education.  Existing developers and managers frequently feel overwhelmed by the backlog of work they face, and frequently even acknowledge that newer techniques would make their lives easier, and relieve some of the maintenance burden.  But instead of learning some new time saving technique, they say "I'll learn it when I have time".  In fact I have been given that ironic excuse by someone who said they wanted to learn newer skills but wouldn't take the time to learn them.

And what about the fear that a newly trained employee will leave in search of greener pastures?  I am unconvinced that this would happen just because you trained them.  An employee, who goes elsewhere, typically will not do it because they are trained, but because they are unhappy with their current employment.  Additionally one of the top ten reasons for this discontent is Lack of Training.  So in my opinion it is more costly to fail to adequately train your IT staff than it is to keep them up to date.  At Star Base Consulting, Inc. we encourage all of our staff to take a week of training every year, just to keep up with the trends.  In addition you can contact Star Base for your IT Training needs in Cincinnati.

On one of the Tech forums I was reading the other day, someone asked "Have you ever been a part of a project where a Business Analyst (BA) did anything remotely productive?"  Why yes, yes I have.  Unfortunately, while this question displays the divide between IT and the business it is supposed to be supporting, the ratio of respondents nodding their heads in agreement to those who actually admitted working with a decent BA shows the extent of this divide.

In my consulting role, I have seen both sides of a client growing from a small department of programmer analysts (PA) to a large IT shop of BAs and Software Engineers (SE).  The transition to enterprise application development pointed out for me the difference between the traditional PA analyst role and the BA analyst role.  And in my mind it pointed out the problems that can accompany the PA analyst role.  The BA is a business role first, and a technical role second.  His job is to collect business requirements and verify that the final product meets those business requirements.  The BA does no programming, and is not responsible for providing technical design of the IT business solutions being provided.  A good BA may not be terribly technical but frequently comes from a help desk background.  He has enough technical experience to talk to the SE, but more importantly has the people skills to talk to the business about their needs.  On the other hand the PA is typically a senior programmer, a technician first, who has learned something about business.  Problem is, this guy typically comes at a problem differently than the business person.  His first priority is finding the problem, and designing a solution.  When talking to the business representatives, the PA will frequently talk in design terms with the business, and frankly, the business doesn't, or shouldn't care if the application is using optimistic or pessimistic locking.  They do care that the users are able to do their work efficiently as possible.

Business requirements are not detail design specifications.  They aren't data design specifications.  They aren't even high level design specifications.  Business rules state that the Customer number must be unique, not that the customer number is the primary key of the customer table.  Business rules state that an invoice may not be created for an inactive customer.  They don't state how that is going to be accomplished.  Design specs are the SE team's responsibility.  And that is a different story.

Java and .NET have been the darlings of web application development now for some time now in most corporate IT shops throughout the world.  In the background are a dozen or two lesser languages and frameworks vying for attention, most still struggling for recognition, or surviving only in the open wilderness of the internet.  As I have said before, business solutions need real survivability.  Many of these offshoots don't have the backing of any corporate entities, and are thus risky endeavors.

One of these, PHP, is in its 5th generation, and making its way into IT shops as an alternative to Java and .NET for web development.  The main proponent of PHP is Zend  who has built a commercialized PHP stack named Zend Core, and placed that stack in multiple environments including, with the help of IBM, IBM's midrange Power Systems.  For those of you who are not up-to-date on IBM's midrange offerings, Power Systems are the newest version of the old RS6000 and AS/400 lines.  I think of Zend as the Red Hat of PHP.  You can get PHP elsewhere, but Zend is instrumental in its development, and provides enterprise level support that can satisfy corporate auditors.

Not only does PHP have an enterprise level support structure, there are millions of programmers and a robust open source community.  This adds up to readily available resources to staff a corporate PHP development project.  Indeed according to the TIOBE Programming Community Index for June 2008, PHP has increased to 4th on the popularity chart surpassing both .NET contenders: Visual Basic and C#.

Finally, a thriving community means ready availability of frameworks to speed application development using modern techniques.  One of these, Zend Framework, provides many of the features and benefits of modern Java and .NET frameworks.

As you can see, PHP is ready for Prime Time in your corporate infrastructure.  Contact Star Base Consulting, Inc. to see how PHP can help you bring your business to the web.

Firefox 3.0 was released last week, and as I use Firefox almost exclusively, I downloaded it.  I am using Firefox 3.0 today as I write this blog.  Open source software has given me some robust, reliable alternatives to the traditional ISV model.  In fact I frequently use nearly a dozen open source titles.  I like open source software.  But the rub against it is real.  What happens when the developer or developers of an open source title that you have come to depend on go away or stop developing the software?  You can get the source, but then what?  The source is probably not that easy to modify to you needs.  You might not even have the technical know how to get started.

Back to Firefox.  There is an entire subculture of plug-ins and extensions for Firefox, and inevitably when a major version release is made, one or more of these pieces no longer works.  Sometimes there is a new version of the extension available, sometimes the extension is important enough to the community that a replacement exists, and sometimes the author has disappeared without a trace.  So then you have a choice don't upgrade or do without.

IT Business Solutions demand some amount of longevity.  Commercial software with customers typically does not just go away without warning.  This is not a reason to avoid Firefox or other open source software.  Just a notice that caution is required when you put your business on the line with whatever software you choose.  Get a service contract from an established company or you may be left holding the proverbial bag.