Part of “Operating Environments in System Development Life Cycle” Series
Before you start
This post is a personal medium post. Any opinion expressed here belongs solely to the author and doesn’t reflect any view or opinion of any company or organization the author was or is affiliated with now. See full disclaimer here.
Part I: Setting the scene
1 | Intro
Recently I had the chance to work on an activity to clarify which boundaries were still relevant when you need to define a set of criteria and apply a set of rules when moving your workloads between different operating environments.
📝 During that exercise, there were some valuable things we thought we could also address somehow, like:
① Have an agreed understanding of what an Operative Environment is;
② Have a clear set of requirements to define the Purpose of each Operative Environment;
③ Have a list of distinct characteristics for each Operative Environment. You need to know why do you need each of them and for what reasons;
④ Have a list of activities and responsibilities for each Stakeholder involved;
⑤ Draft a set of Principles, Rules, and Guidelines for each Operative Environment and what you need to guarantee while transiting between each environment;
⑥ Have a matrix to map your current Data Center Design against each Operative Environment, considering things like SLA’s, SLO’s and further DR/HA requirements;
⑦ Have a matrix to Map the current Application Portfolio against each Operative Environment;
🤦 If you’re still an IT Shop trying to align your SDLC methodologies and practices to the current and future portfolio of IT/SI Systems, you will probably end up with some endless discussions during your journey.
At first, I found this a little bit strange because:
The way we deliver code in modern day software development is more or less the same across most places. It boils down to a software development life cycle (SDLC) and product/project planning and can be broken down into several activities
And in fact, that is still true. We have not changed significantly during the last few years!
Nevertheless, I found several reasons for having such discussions along the journey:
① Each Stakeholder has its own set of requirements that became somehow difficult to manage and further align when moving between each SDLC phase;
🌪 ❝ BOUNDARIES are not that clear after all❞
② People tend to keep their old mindset still when there are a lot of things that have already changed completely;
People like a lot to cherry-pick facts that support their existing mindset
🤔 ❝ They BELIEVE things have CHANGED but FORGOT they also need to CHANGE on the JOURNEY❞
🤲 ❝ They BELIEVE that there is no need to LEAVE the PAST in order to build the FUTURE❞
— Immortal Technique
③ People live with the pressure to deliver fast and frequently. People tend to focus more on the HOW, less on the WHAT, and miss the WHY entirely;
⌚ ❝ They try to just follow a GETTING THINGS DONE (GTD) pattern❞
🙋 ❝ They FORGOT to ask what are the THINGS that really matter to be DONE❞
🌁 ❝ They tend to FOCUS on the daily-to-daily Operational side, and always leave Vision & Strategy for later…❞
④ In fact, it’s tough to change and still maintain your current and legacy ecosystem at the same time if;
People misunderstand new technological paradigms and over extrapolate their potential to solve organization or process problems
⏳ ❝ And maybe because of that, for the most of us, BIMODAL is not really an option anymore❞
Because the operating environments still used today are somehow linked to the methodologies and practices adopted from the System Development Life-cycle (SDLC) of the past.
The question is:
📊 ❝ Are they still suitable in this Digital Age where you could have different types of workloads with very different length life-cycles to be deployed?❞
As such, when you think of “What could be a Strategy for a new set of SDLC Operating Environments,” there is no easy and unique way to get an answer.
And maybe because of that, those operating environments are being redefined and redesigned.
✄ ❝ On one hand, they are been challenged on their own purpose. On the other hand, on their nature and the related set of characteristics and facilities provided❞
Or maybe you are just asking the wrong question.
The reason behind this is that there are many things that you need to think about altogether. It’s not enough to look from the past into the present.
“Whatever happened in the past belongs in the past. Learn from it, grow, and move on. Don’t let it determine your future.”
― B.J. Harvey
✍ So, what are the things that we can still ask and try to learn from our experience if we believe we can use those things to learn, grow and move on?
① Which operative environments are we using today and why?
② Which problems are we facing today?
③ Can we still try to solve some of them?
④ How did we get here?
⑤ Are there any other concerns that we could use in this learning process?
⑥ What has already changed what we have?
⑦ What is challenging what we think we know?
⑧ Can we understand why?
⑨ What previous blunders and mistakes do we want to avoid?
⑩ Are we asking the right questions that we need to address?
👀 And, instead of just discussing what criteria and rules should be defined and applied to transit between boundaries, maybe you should focus instead on understanding what is challenging which boundaries nowadays. And what has already changed in between.
🙌 ❝ If every Operating Environment is supposed to be used with the purpose to streamline and ease the delivery of some value related to a Product in your Value-Chain, then you surely need to take a step back❞
And ask instead:
① What is your Organizational Strategy to deliver what Value for what Products;
② What kind of Delivery and Learning Pipeline should you build to make sure your Value-Chain will succeed;
And last but not the least
③ What must be put in place to keep these products moving forward?
In the end, a “Strategy for a new set of SDLC Operating Environments” it’s a part of a broader strategy to design and implement a unified Delivery, Monitoring, and Learning Pipeline for your workloads. But the Strategy also needs to address other concerns.
Before you go
Make sure to follow me on Medium if you want to receive my future articles. And if you liked this one on the “Operating Environments in System Development Life Cycle” Series, I think you’ll also enjoy the rest of it.
You can always support it by buying me a coffee here. Or simply just sharing your feedback.
In this part one, I’ve highlighted the questions to ask instead before discussing which operating environments to use and how they need to evolve or look like in the future.
In part two, I will cover a little bit of history and highlight some facts to understand how we got here. We should learn from the past to move forward.
In part three, I will show how applying a framework could help clarify the relevant strategic concerns to discuss further while understanding the challenges for setting up new operating environments.
In the end, in part four, I will highlight how Operating Environments will look like in the future.