All Posts in Technology

|In: AI|Last Updated:

Those of us who grow into Leadership in IT do so primarily powered by one driving factor—our curiosity.  Curious nerd-dom  has been a dominant theme in this community.  You wouldn’t be reading this column if you hadn’t been interested in how you could take technology and use it to solve some sort of business problem.

Aw, no, sorry. If we’re going to be honest with each other … and I can trust you with a secret, can’t I? … you were less interested in how technology could solve business problems than you were interested in a seriously cool innovation of some kind.

Because it was seriously cool, you wanted an excuse to play with it. That excuse was that it could solve some business problems. You needed the excuse because our business counterparts frowned upon us IT nerds just wanting to have fun.

And just as you saw the potential in a cool technology and explained it with enthusiasm, your colleagues saw the potential in you. Or likely, lots of other people saw this in you, as you worked to address some challenges that somebody mentioned to you or that you saw in your own. You probably had some sort of “Eureka” moment that you remember clearly about how you made some sort of new magic happen, and it was driven in part by your curiosity.

Don’t be shy – share your experience of this in the Comments.

Recognizing the power of curiosity, you may have used this as a criteria in how you have grown and managed people in their careers as well—I believe that in every organization, we are looking for others that can solve a problem innovatively.  We see people with these strengths as worthy of our trust, and we are more likely to wish to work with them, mentor them, and see them flourish and grow.

There are countless bitchy columns complaining about Millennials and Gen Z workers, and their poor work ethics.  This flannel wearing, grunge listening, Gen X columnist rejects these ideas as utter nonsense, having heard the same disparagements aimed at my cohort.    But, I do have a warning and plea—We need to continue to encourage curiosity, on the clock, and off, for our staff to grow and thrive.

Since we are starting to figure out what AI will do to our profession,  let’s point out that AI is insatiably curious.  It doesn’t care about politics, Tik Tok trends, cat videos or anime movies( or at least, it has the same unlimited curiosity for each of these topics.)   It is always interested in studying what others have posted on GitHub, or any other place that there is new content.  AI doesn’t sleep, and doesn’t want to take PTO.

The results of this—New hiring for developers (and others) has slowed  to a crawl.  In talking with others, new engineers, PMs and others at the entry level are having a hard time getting hired, regardless of the specialty.

What is to be done?

Well, I for one, welcome our new AI overlords.

But, on top of that, I would ask all of us to coach, mentor and encourage our staff to not get distracted, always be learning, and find our super powers of curiosity.  A few nights and weekends of growth and self directed learning turn out to be the key to many of our careers. And we need to help others find this answer as well, so that they can continue to build meaningful careers.

Comments

|In: Cloud|Last Updated:

Hey—You know that spreadsheet you have been keeping for the last 15 years about Non Functional Requirements?  You know the one—With references to uptime, Recovery Objectives, and user counts?

In a cloud environment, many of these NFRs are just plain irrelevant.   For example, Point in time Restore (PITR) makes older discussions about Recovery Point Objective and Recovery Time Objective seem like we might be talking about reading the TV Guide to learn when the Ed Sullivan show is on.   It just dates us.  Elasticity and Scalability can more or less handle changes in user loads instantaneously, (as long as the budget is there, and the options are selected).

However, now that we have solved these problems, there are new considerations that we need to manage for in NFRs.   Not surprisingly, not all cloud providers will tell you about some things that you need to ask for or check on.   Whether you are moving an enterprise application to the cloud or considering a SaaS application, NFRs still matter.

In no particular order, you probably want to consider these points in your updated, cloud hosted NFR document.

 

  • Performance and reliability metrics and testing still matter, and should be tested with analogous loads and user scenarios. If you are doing this now, keep doing it, adjusting the tools needed.  For the record, we happily use Locust as one of our go-to tools.

 

  • Data Residency. Where is your cloud (processing, storage, and anything else) physically going to reside?  Will it be located in the same country you are in, and applicable to the regulations you expect?  Or will it be hosted somewhere that doesn’t respect GDPR, California CCPA, FedRAMP or other applicable regulations?

 

  • Can you “exit” your data to a different cloud storage environment as you wish? Let’s call this factor  “Data Portability”.    Along these lines, how do you access your data, whether you exit or not?  (Note—You really, really want to test this out, prior to fully committing to a vendor)

 

  • How much notice will the cloud hosting company provide you with before planned outages or maintenance? Not naming names here, but in our experience some providers show little concern about announcing outages or dealing well with cleaning up the mess they can leave behind after maintenance.   Some cloud providers even fail to count “scheduled maintenance” against downtime, even if their data center is on fire.

 

  • Highly related—Most cloud providers offer some sort of security as a service add on, and you will probably want it. But, it would be good to know exactly what their “Armor” actually covers—and what it doesn’t.

 

  • You will likely be asked by somebody about cost predictability in your NFRs. This may or may not be a big deal, but nobody likes surprises.  You want to at least ask the question about how stable your pricing will be, even with potential elastic changes in loads or users.

 

Bottom line—We all actually need to think about NFRs more now.  At the very least, we need to update our spreadsheets, but perhaps more importantly, we need to creatively think about how to avoid treating this as just a rote piece of busywork.

Comments