Developer / Solutions Architect

I have been involved with software development since the mid-1980s, beginning with basic programming tasks and advancing to the development of client-server and web-based applications. As I transitioned into pre-sales, my focus shifted away from active development. Now, I primarily apply my software development knowledge to lightweight integration and data manipulation for proof of concept purposes, utilizing APIs, and understanding the realm of what is possible.

I have functioned as a stand alone developer as well as a lead developer on large projects.  A role that I usually fell into was as the SCC manager at a time before everyone was using Git  / GitHub, JIRA and SCC was typically relegated to larger projects. I also was often tasked with database design/re-design and ETL tasks for migration and ongoing data load use cases.  I worked with several customers over the years off and on to maintain and extend their business databases and database forms, queries and ETL processes.  Some of my software projects include:

• Seibu Giken - Industrial product sizing and selection software.  This was an extension of work I did at Air Technology Systems as a Sales Applications Engineer.  Windows forms based solution with Access database for product and project data.  Sales reps would enter their data for the air conditions (input and desired state) and could pick from a suitable list of products and get a drawing output with all engineering numbers suitable to submit for bids without having to ask the factory to generate it.  This included creating the installers and media.  Project was ongoing for 15 years.  Roles: sales, dev, QA/QC, PM.
• OAO - SCC manager and dev lead for windows forms solution utilizing Oracle as the backend.   Reviewed all developers code, enforced SCC usage, recommended database design changes, optimized queries for performance.  Participated in delivered product reviews and requirements sessions with customer.
• DME provider - Sales and inventory tracking software.  When new inventory arrived, bar codes were generated and put on DME and scanned into the solution.  This ensured the entry of a full order into the inventory system or generating an exception to be resolved.  Inventory was then tracked through leaving the facility and entries made via api to the accounting system.  The solution eliminated theft and provided full tracking of any given item from receipt through sale.  This was a windows forms solution with an MS SQL database. Roles: all.
• Real Estate Association - Created web based association portal to provide information to members and to collect and process dues.   This included the processing of credit card payments and posting of transactions to the accounting system vis API.  This was a .Net application developed in C# with an MS SQL database and using iis. Roles: all.

In the pre-sales role, no matter what it is named, you are often called upon to fullfil the role of Solution Architect.  In this role our concern is typically how do we get product or product stack X to work in environment Y with associated systems Z1-Z10.   And it is very important to be well versed with the associated technologies which were often: OCSP, AD, other auth, SSO,  iis, apache, load balancers, storage technologies, firewalls and a slew of other things.  Additionally, you need to have a good story regarding HA and failover/failback and that was often not the best part of most products.  To add to the fun many of the environments I deployed to required the use of STIGs which were a great way to make any product not work and that opened up a ton of doors to be creative and many discussions with IA teams.

Things progressed with many things moving to "appliances" which eliminated the need to STIG in fed environments and generally got you more of a pass than you should have in the commercial space.   Deployment to Virtual environments controlled by VM management technologies mostly eliminated the requirement from prospects for a good HA and failover / failback story.   But, in reality it shifted the requirement for many of them to do things most would not ever implement properly for the architectural element.

In the last several years the discussion has almost totally left local VM management and moved to whether it deployed in AWS, Azure or GCP and to what regions.  The use of regions again got vendors off the hook as far as coverage and HA but in reality generally were not actually deployed with a multi-region setup and thus affected by downtime of a single region which has come to pass for some heavily used cloud regions.  Today you see astute buyers asking for details on that, you didn't get that question 4 years ago.

In the last 10 years I have watched many solutions created and grow in the SAAS model deployed mostly in AWS and today almost exclusively with the CI / CD model.    I have become familiar with what is expected from any proper SAAS solution and what they should be made from to scale and to be resilient.  The use of Kubernetes pods and clusters is a key that I want to see because now the failover is handled at the architecture level not at the application level where it used to be done (or often sort of or not).

I could go on and on about the architecture side.  What I want you to take away from this is that I have had the benefit of seeing how many products work and don't work, due to architecture, as well as the challenges posed by certain markets.  I have also had the benefit of seeing how some really incredible people have designed their SAAS offerings to scale and perform.  Some specific markets where I have specific extra knowledge include: highly disconnected environments, MSSP requirements and designs for Fedramp.

I can share one prediction I got from a Federal client that may spread: a requirement to have no applications accepted on appliances (virtual or non) because they cannot be directly hardened or monitored with the expected harness of security tools and policies.

Recently, I have transitioned to modern technologies such as Git, GitHub, and Python. My experience also extends to Docker/Containers, OCSP, Bloblang, Snowflake, and the evolving landscape of SIEM. Additionally, I am pursuing courses in ML/AI and related data science fields.

This does not imply that I am aiming to become a production-level developer or delivery architect. Rather, it signifies that I am staying abreast of, and occasionally ahead of, the technological curve. This background and knowledge equip me to scope and deliver solutions for bids, design architectures to penetrate new markets, evaluate partners and their technologies, and liaise with delivery personnel.