I’ve now been in technology for over 30 years. I don’t feel old, I just started young! In addition, it seems I’ve been doing a lot of the same things and it’s only now I’ve started to realize it’s really ALL all been around integration and process improvement.
My first job was taking mailing address reply-address cards and typing the info into a pretty dumb green screen application (Reality PICK system). I didn’t like the process so I taught myself programming to make the UI and data entry easier and faster. Into the code I went, writing shortcuts for auto filling large parts of the addresses, auto formatting and validating phone numbers, auto searches for checking there were no duplicates and if there were, automating the merging of the records. Sure there was only one server and only one UI, but writing technology to make this single process more integrated (and more efficient) was really the start of my IT career. I was hooked and from then on built on the art of making things easier for users.
I moved onto writing performance monitoring and benchmarking tools after that, trying to automate the processes that would find ways to make things go faster. Trying to squeeze every usable drop out of the CPU by eliminating code that wasn’t necessary or was written badly. When our “mainframe” added support for more than one printer for a payroll application, I found the code to be so bad as to slow down both printers to the point they were printing slower than one printer (buffer sizes were tiny back then). That was known as contention or thrashing. I’d go to the server side code and work out myself how to fix it.
Then I started writing full enterprise applications. First in code and then moved onto 4GL’s. I was the first to report to my CEO that our claims that our 4GL runtimes were slower by a factor of 3, not faster as we had been claiming. I even wrote the application again in code, deliberately bad enough to replicate what I knew the 4GL had to do differently. Alas the 4GL runtimes were extremely poor by comparison. Instead of being fired by my CEO, I was promoted into the performance/benchmarking improvement teams. We optimized so much technology over the years, everything from hard drive buffering and striping to CPU management to building assembler objects to help developers code run faster.
I formed my first company at the age of 25. Simply, we were a terminal emulation company with a twist. We enabled enterprise applications (mainframe / server side) to be integrated with the new UI’s (DOS, then Windows). Lipstick on a pig it was sometimes called but it truly delivered faster, cleaner and fully integrated user experiences than traditional silo’d UI’s at the time. It solved what used to be called swivel chair integration problems. We sold over 500,000 seats so I like to think it served a purpose. I also know today, 22 years on, people out there are still using “my” intelligent terminal emulation to do their jobs. HOSTACCESS, now owned by RougeWave.
So what does this all have to do with our failures in Integration I hear you ask? Be patient, I’m nearly there.
First, almost from the very birth of IT, integration was an issue. If two people each build an application or process, almost immediately there is likely a need for these 2 bits of code to work together. If neither coder knew of the other than chances are, making those 2 applications work together would be hard to impossible without some form of re-engineering. Sure, both coders could have made their applications “open” (maybe we call that services today) but even then, there is no guarantee that the services would be compatible, that the interfaces would be logical or even that the business logic would be the same. Even if you successfully integrate these two, along comes the 3rd coder with their application and off we go again but now we can’t risk changing the 1st or the 2nd coders interfaces or business logic for fear of breaking something for the customers using those first two interfaces. Okay, to fix that, we could just make a copy and of each of the first two applications and make them work with the third. Ah, so now there are five apps. We are now on the exponential interface path. To the power of n, our integration woes are born.
Second, as if anyone is in any doubt, that integration isn’t simple, just look at the fact that enterprises have users commonly using 4, 5 6 or even over 10 applications on their desks to do their jobs. Copy and paste rules. Sad but true, right? Unless you are a big bank, with $100’s of millions to invest in re-architecting or re-engineering to a single common UI, then your users are likely living in an silo’d un-integrated world. Sure you may have some integration working but the truth lies in what your users are doing. If it’s just one application with easily navigatable workflows then congratulations, you deserve lots of credit. Chances are, you’ll have more apps and UI’s next year than this. Keep those copy paste keys warm!
So you see, technological advances have not really changed very much since I was doing this 27+ years ago. Sure we have greater technology and the processes are different but as a user – at the coalface, are you really better off?
Difficult to blame IT because even if you are one of the lucky organizations to be able to move to just a single application and UI, I bet you, it won’t be long before your organization buys up or merges with another company and you’ll be back to square one again.
What I have been a proponent of, for over 20 years are standards in API’s. And as importantly, standards for API’s at the front end as well as the back end. Today, as always, we are building applications where the business logic crosses 2,3 4 or more layers (the database (triggers, rules) ), server side (deployment, scale), the server side logic, client side (scripts, multiple UI platform, devices) and even more logic on logic rules in between.
How can we blame IT when we have had more standards pushed down the throats of IT in the last 20 years than there are adapters for our mobile devices :)
API’s for UI’s are as important as the API’s for or services so that whatever a developer builds, in any of these layers can quickly and efficiently, be lightly coupled with other API’s. Time to market for business is huge and IT can focus on deliver ingthis to their organization. Time to come together, once and for all. First end the blame game and then play the “results” game.
Process Optimization is not just a job at the server, never has been, never will be.
Category 
