Introduction

Preface to My Moment

As a professional software architect, one of the enjoyable parts of my job is attending user conferences. Typically these are large events, during which knowledge can be acquired and professional contacts made. Lest I forget, both the hosting company and many of the exhibiting vendors are usually prepared to wine, dine and generally schmooze customers as conferences are a wonderful sales cultivation opportunity for them. Leave it to say, a user conference is a place to learn, meet people, and generally have a ball in the process.

Recently I attended one of these conferences, during which I came to one very uncomfortable conclusion. I’m not nearly as smart as I thought.

There it is, my ugly moment of truth. I had allowed myself to become technically complacent and fallen out-of-date with my kind of technology. If you happen to be in the business of information systems, then you are probably aware, that out-of-date is as professionally deadly as the ebola virus and simply not to be tolerated.

Nothing but the Truth!

During the conference, I attended session after session that was filled with technical references to topics, which I understood conceptually, but had never used or laid my hands on. I knew very well what the phrase “Continuous Integration” referred to and could define it and even use it in a white paper. But I had never actually constructed nor personally worked with a continuous integration process. The same was true with:

• Continuous Delivery
• Microservices
• Container based Deployment

… and to my uncomfortable chagrin this list could have been much longer.

The session descriptions, in this conference, were filled with these somewhat familiar words and phrases, which are considered vital to the future of information services technology.

Currently, the evolutionary direction of information services involves the integration and adoption of “cloud computing” or to use popular tech-speak ‘moving to ‘the Cloud’¹. For those of you who are just salivating for a clean, precise, textbook definition here, how about …

“Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction”². Now that is one fine example of the tech-speak mumbo jumbo for which computer folks are so famous. (Although, I think medical folk are just as guilty.)

For the rest of us, I should simply explain that my little bit of corporate America is currently consumed with the idea of ‘the Cloud’ and our best and brightest all agree working in the Cloud involves all the the concepts mentioned above. So, being able to spell them and use them in a sentence, regardless of how long that sentence may be, is just NOT good enough!
But how did a hip, young (OK, kidding myself there), technologist like me get into this situation. Hmmmmmmmmmmm. Let’s think about that. Not because I haven’t already, but I think there may be a few others out there in a similar situation.

Familiar Turf

My primary role does not involve developing software. I’m no long a developer by profession, heaven forbid! After years in corporate IT, I’ve successfully ascended the corporate ladder to the lofty position of Software Architect. So my colleques find it absolutely unseemly that I continue to dirty my hands writing code. After all, that’s for developers!

However, as a Software Architect, I am still expected to have knowledge of the development process and its associate skill-sets. I have always felt the best way to achieve and maintain this knowledge is to stay ‘hands-on’ with development tools and the overall SDLC³ process. For a number of years now I have happily coded in Java, whenever I could conjure up an excuse. Occasionally I produced batch tools and web-based applications using J2EE⁴ concepts. This means that I’ve worked primarily with command line applications and on-line applications made up of servlets, Java server pages, and relational databases.

My patterns of development have been to develop using the Eclipse IDE⁵ to create and unit test my Java code. Since I work alone, using a Source Code Control system has usually felt like overkill to me. Instead, I make periodic copies of my project folder, and include the source code in the various Java Archive files I generate. This is definetely a low-tech, means of protecting myself from inadvertely deleted or damaged source code, but its worked quite effectively on my team of one for years.

For testing, my normal pattern is to use the main method of each class as a testing harness from which I can construct and run unit tests. Once I’m ready for subsequent testing, I generate an appropriate form of Java Archive (JAR⁶ or WAR⁷) and manually deploy the archive and any required other required archives to the destination environment. Then I can perform various types of testing on the application.

In the last few years, I have branched out from J2EE web applications into creating Ajax⁸ applications using the jQuery⁹ library and REST¹⁰ based web services on the back end. I felt this indicated that I was staying up-to-date and was still with it. Was I ever wrong!

How did I get Here

As I learned in the conference, many of my design principles, development processes, and tools were indicative of the way I have been working. Predominantly in isolation! Most of the time I create applications by myself. That means I have never personally used the techniques and the products necessary to produce software on a larger scale in a team based environment.

So What Now …

The cure for out-of-date is well known. Retool or Retire! I’m not ready for a rocking chair yet so I guess my choice is clear. The question is how to go about it?

My answer is going to be very consistent with my career path. I’m going to get my hands very, very dirty. I’m going to build a website! But much more than that, I’m going to built a website based upon non-existant requirements such as:

• It must be scalable up to many thousands of transactions per second
• It can effectively be coded by a team of developers
• It supports an effective DevOps environment
• It can be continuously updated and redeployed without interruption

By imposing these artificial requirements on my application, I will create a situation that I must learn and utilize most of the technologies with which I’m currently lacking personal proficiency.

A Change in Plans

So, I’ve been planning on creating a family website. However, up to this time it was largely a means to an end. As such, I planned on using an rather old fashioned, tried and true, approach a standard J2EE website. Yup! Time to get the job done and stay in my comfort zone doing it. In fact, I have a relational schema already implemented in a cloud based instance of MySQL for just that purpose.

But now I’ve had my Moment of Truth and those plans will have to change. I’m still going to create my website, but based on my new made up requirements, it is going to be very different from what I was planning a week or so ago. As I mentioned above, I’ve done some work already. So the best way to take a next step, is to describe the application I’m going to build.